musl new-year's infrastructure resolutions

musl new-year's infrastructure resolutions

[Rich Felker]

Here are some things I've really been wanting to get done for a while,
that I/we should try to make happen in the coming months:

Switching over wiki. The current wiki is essentially unmaintained.
Kylie McClain (Somasis) has setup a clone of the content on a new
git-based wiki that looks good. I still want to understand the
intended workflow for getting changes published, but it's got to be
better than the status quo where account creation doesn't even work.

Adopting an issue tracker. This requires actually selecting one and
setting up the infrastructure for it. The wiki could possibly be moved
to the same infrastructure. (I want to keep webapp-ish stuff like
wiki, issue tracker etc. off the server that hosts git and release
downloads because anything interactive is a significant attack
surface that puts integrity of code as risk.)

Enabling git-over-https. This may require switching to a more-capable
httpd or other infrastructure changes on the server.

Website redesign and move to musl.libc.org. I don't have any concrete
ideas for this yet, but I don't think the current website is at all in
line with musl's maturity, current adoption/deployment, etc.

Documentation. Existing manual should probably become a public git
repo that contributors can submit patches/PRs for. Putting together
lists of (1) what's outdated in the current one, and (2) what new
content would be most valuable, might be a good place to start and one
that could benefit from community involvement.

Re: musl new-year's infrastructure resolutions

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 31/12/16 17:37, Rich Felker wrote:
> Here are some things I've really been wanting to get done for a
> while, that I/we should try to make happen in the coming months:
> 
> Switching over wiki. The current wiki is essentially unmaintained. 
> Kylie McClain (Somasis) has setup a clone of the content on a new 
> git-based wiki that looks good. I still want to understand the 
> intended workflow for getting changes published, but it's got to
> be better than the status quo where account creation doesn't even
> work.
> 
> Adopting an issue tracker. This requires actually selecting one
> and setting up the infrastructure for it. The wiki could possibly
> be moved to the same infrastructure. (I want to keep webapp-ish
> stuff like wiki, issue tracker etc. off the server that hosts git
> and release downloads because anything interactive is a significant
> attack surface that puts integrity of code as risk.)


Are you looking for hardware, or for admin volunteers?  No matter how
much I hate wearing the admin hat, I seem to be pretty good at running
stable Bugzilla servers, if that's something you are interested in.
It's one of the most flexible of the FLOSS issue trackers.

I'm not sure that you would be interested in running it on our infra,
seeing how musl is a distro-agnostic libc.  However, I would certainly
be willing to help you get everything set up if you want help.


> Enabling git-over-https. This may require switching to a
> more-capable httpd or other infrastructure changes on the server.
> 
> Website redesign and move to musl.libc.org. I don't have any
> concrete ideas for this yet, but I don't think the current website
> is at all in line with musl's maturity, current
> adoption/deployment, etc.


Are you additionally taking suggestions here?  I might be able to mock
something up.


> Documentation. Existing manual should probably become a public git 
> repo that contributors can submit patches/PRs for. Putting
> together lists of (1) what's outdated in the current one, and (2)
> what new content would be most valuable, might be a good place to
> start and one that could benefit from community involvement.


I would love to contribute good/better documentation to musl.  If you
could make those lists I would definitely see what I could contribute.


- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYaYSNAAoJEMspy1GSK50UBSAP/2M0zXkqmeklzQcJDVpjfhf6
8C7BlsHq+YEzGcjlGpqnonYgEmnzcLeLy04FiIWyiOJraqebMNy2R1iFRTXIUX/d
voiL1GCGiP74dHMLHYIZeevHpkc2nA+0XNB5dLKhg0vYSWIMdK6n3VDT2EBjK8UO
fYXEXHGDBTCvCdkrJ44uJG1J5vPaQBFtZFhtWYk9GaC/V/ZF6bQJ+xTpxgmfShkq
Z54b0uNztuXBG+y+r09MaJgtjfBsf3oYUhD7/OMArBx2iXk9o6vRMxTONKlU87g5
IBxzU5vhYmgJ4wxarcwvCvd19yd346SKcwG1YvT//j8NQEJY+M5o21z3fCEyKWDb
cTeGSVSzYQq2k+9wkLSo/weMsf4ipCJue/A821HJCLohi9ryFLN0d+oM/Hph8CzB
otb2KgMlMTyfTLf66cFOqilwsVCVJAG/OuRPXZ5CG9l/WWS3THO5/IQ8N1jmmFbO
D+O2ezz0y2RKRkMqeTpPFAY034KmbeZMgRYNp07ZH7I3xSc0585uJl5mEJLEUd6B
KrHgg7ofReIPvSTUln0WJt9yaTL6layKUFxJC559QwE4PiYYVeeBZnhwY8WCc7X9
lArjfJz43Y33OOXXf/VCdgFR/xnmhldJdcogo3jq4OVGnhpHVzEH4QYPiu3OluM2
Cdlme+oXsGSmUFXjtRye
=abQE
-----END PGP SIGNATURE-----

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Sun, Jan 01, 2017 at 04:37:04PM -0600, A. Wilcox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 31/12/16 17:37, Rich Felker wrote:
> > Here are some things I've really been wanting to get done for a
> > while, that I/we should try to make happen in the coming months:
> > 
> > Switching over wiki. The current wiki is essentially unmaintained. 
> > Kylie McClain (Somasis) has setup a clone of the content on a new 
> > git-based wiki that looks good. I still want to understand the 
> > intended workflow for getting changes published, but it's got to
> > be better than the status quo where account creation doesn't even
> > work.
> > 
> > Adopting an issue tracker. This requires actually selecting one
> > and setting up the infrastructure for it. The wiki could possibly
> > be moved to the same infrastructure. (I want to keep webapp-ish
> > stuff like wiki, issue tracker etc. off the server that hosts git
> > and release downloads because anything interactive is a significant
> > attack surface that puts integrity of code as risk.)
> 
> 
> Are you looking for hardware, or for admin volunteers?  No matter how
> much I hate wearing the admin hat, I seem to be pretty good at running
> stable Bugzilla servers, if that's something you are interested in.
> It's one of the most flexible of the FLOSS issue trackers.

Given how things turned out relying on a volunteer admin for the wiki,
I'm probably more looking for someone with experience setting the
chosen tracker up so that I don't have to figure out everything
myself. I'm familiar with and like Bugzilla from a user side, but IIRC
it requires some ugly legacy hosting infrastructure; is this correct?
(I.e. does it need particular old-fashioned server/db sw like Apache,
Mysql, etc. or can it be used with more modern alternatives?)

> I'm not sure that you would be interested in running it on our infra,
> seeing how musl is a distro-agnostic libc.  However, I would certainly
> be willing to help you get everything set up if you want help.

Yes, that would be great.

> > Enabling git-over-https. This may require switching to a
> > more-capable httpd or other infrastructure changes on the server.
> > 
> > Website redesign and move to musl.libc.org. I don't have any
> > concrete ideas for this yet, but I don't think the current website
> > is at all in line with musl's maturity, current
> > adoption/deployment, etc.
> 
> Are you additionally taking suggestions here?  I might be able to mock
> something up.

I can't promise I'd use it, but a mock-up would be nice as a source of
ideas for content and presentation. For the final site I want the
backend to be like it is now, makefile based, but with markdown source
files for the content and html-fragment templates/css for the design.

> > Documentation. Existing manual should probably become a public git 
> > repo that contributors can submit patches/PRs for. Putting
> > together lists of (1) what's outdated in the current one, and (2)
> > what new content would be most valuable, might be a good place to
> > start and one that could benefit from community involvement.
> 
> I would love to contribute good/better documentation to musl.  If you
> could make those lists I would definitely see what I could contribute.

IMO the most important things that need to be documented are:

1. Everything implementation-defined that ISO C or POSIX requires.
   Just making the list of these things is a big task. I think I
   started it once and have notes but I don't remember for sure.

2. A list of all the nonstandard extensions supported by musl, both
   extension functionality to standard functions as well as extension
   functions, with documentation on how they behave. This would
   probably take the form of a reference to some other document (like
   Linux man pages) or implementation (like glibc) with differences
   explained clearly.

Rich

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Sun, Jan 01, 2017 at 09:31:39PM -0500, Rich Felker wrote:
> > > Documentation. Existing manual should probably become a public git 
> > > repo that contributors can submit patches/PRs for. Putting
> > > together lists of (1) what's outdated in the current one, and (2)
> > > what new content would be most valuable, might be a good place to
> > > start and one that could benefit from community involvement.
> > 
> > I would love to contribute good/better documentation to musl.  If you
> > could make those lists I would definitely see what I could contribute.
> 
> IMO the most important things that need to be documented are:
> 
> 1. Everything implementation-defined that ISO C or POSIX requires.
>    Just making the list of these things is a big task. I think I
>    started it once and have notes but I don't remember for sure.
> 
> 2. A list of all the nonstandard extensions supported by musl, both
>    extension functionality to standard functions as well as extension
>    functions, with documentation on how they behave. This would
>    probably take the form of a reference to some other document (like
>    Linux man pages) or implementation (like glibc) with differences
>    explained clearly.

BTW for reference here is the current (well, outdated) manual:

http://www.musl-libc.org/doc/1.0.0/manual.html
http://www.musl-libc.org/doc/1.0.0/manual.txt
http://www.musl-libc.org/doc/1.0.0/manual.md

The md version is the source for the others.

Rich

Re: musl new-year's infrastructure resolutions

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/01/17 20:31, Rich Felker wrote:
> On Sun, Jan 01, 2017 at 04:37:04PM -0600, A. Wilcox wrote:
>> On 31/12/16 17:37, Rich Felker wrote:
>>> Adopting an issue tracker. This requires actually selecting
>>> one and setting up the infrastructure for it. The wiki could
>>> possibly be moved to the same infrastructure. (I want to keep
>>> webapp-ish stuff like wiki, issue tracker etc. off the server
>>> that hosts git and release downloads because anything
>>> interactive is a significant attack surface that puts integrity
>>> of code as risk.)
>> 
>> Are you looking for hardware, or for admin volunteers?  No matter
>> how much I hate wearing the admin hat, I seem to be pretty good
>> at running stable Bugzilla servers, if that's something you are
>> interested in. It's one of the most flexible of the FLOSS issue
>> trackers.
> 
> Given how things turned out relying on a volunteer admin for the
> wiki, I'm probably more looking for someone with experience setting
> the chosen tracker up so that I don't have to figure out
> everything myself. I'm familiar with and like Bugzilla from a user
> side, but IIRC it requires some ugly legacy hosting infrastructure;
> is this correct? (I.e. does it need particular old-fashioned
> server/db sw like Apache, Mysql, etc. or can it be used with more
> modern alternatives?)


I disagree with calling Apache 2.4 "old-fashioned" - mpm_event works
quite well - but it is just good simple CGI.  It can run anywhere Perl
can.

It supports MySQL/MariaDB, PostgreSQL, Oracle, and SQLite3.  While I
prefer pgsql over the others, I'm not sure I would call any of those
"old-fashioned" either.

Assuming this isn't acceptable, what do you consider "modern"?
Unfortunately I have experience with over a dozen issue trackers, so I
can likely match you to *something* that would work for your
infrastructure.

- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYaeXcAAoJEMspy1GSK50UmnkP/3D+D3vAAvy1vSXsdFlgDDjM
j29zfji7TjKO6/R8NBPca626iT3uiZcY5kRfcu1ItM0cJJq2qnJ395M3MdPQJc5C
lH+VWP2mhrhcL5px+DGADxjukhOZg09dKB6+D2zVC14AfocRwxER2wQJStZI4pri
fIYT+Lmia+U6K5T9GrOTueIB5xmXpG3QvN7ccJaj33cW2XiylkJXi3iSB77J2c3b
Ay6IAYjJ0BNjLCFHCTCzec+gJw2bRAKQsTH+joOOMPpjwUoA6n4cs9LnBvLnEoNU
EsNxTPRK/zY5MpHZmSZYnTO4BimcW/nOXvoNuDmJScyKo+H3hBv3OMs1551n2gmR
kELScBnLrh1lw2YIC9iJD8r+IyRj3VMiOhnry6mp5nOzf61g+Y3kJhJY7AZE7KHa
KRa/yT53hjhcPAf2yS24QKbPM5NqsPsTgSy4wj4sfqmyn6dHSKRl/qHBXRPmHwYG
BwkXlhsJ0E7WtnKO4P3jGqed7WfuM9HMi1hlNy7pRZtDyQM3bxBwil5eEMTgvNvq
g9dIfaSGshuCOLQsmBC5OzeXBdlOccQhra0s0mJpZEuFggs4a2R8afidZxXt1Qv/
uRQdQUEDoN0nGqG+f6VhLhIuC3RdLQe1yahKFKP+yaiJSP0KpyO4W4KmM/A9QnUg
oqttC1O+OtxhoPs1qLK2
=ObeE
-----END PGP SIGNATURE-----

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Sun, Jan 01, 2017 at 11:32:21PM -0600, A. Wilcox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 01/01/17 20:31, Rich Felker wrote:
> > On Sun, Jan 01, 2017 at 04:37:04PM -0600, A. Wilcox wrote:
> >> On 31/12/16 17:37, Rich Felker wrote:
> >>> Adopting an issue tracker. This requires actually selecting
> >>> one and setting up the infrastructure for it. The wiki could
> >>> possibly be moved to the same infrastructure. (I want to keep
> >>> webapp-ish stuff like wiki, issue tracker etc. off the server
> >>> that hosts git and release downloads because anything
> >>> interactive is a significant attack surface that puts integrity
> >>> of code as risk.)
> >> 
> >> Are you looking for hardware, or for admin volunteers?  No matter
> >> how much I hate wearing the admin hat, I seem to be pretty good
> >> at running stable Bugzilla servers, if that's something you are
> >> interested in. It's one of the most flexible of the FLOSS issue
> >> trackers.
> > 
> > Given how things turned out relying on a volunteer admin for the
> > wiki, I'm probably more looking for someone with experience setting
> > the chosen tracker up so that I don't have to figure out
> > everything myself. I'm familiar with and like Bugzilla from a user
> > side, but IIRC it requires some ugly legacy hosting infrastructure;
> > is this correct? (I.e. does it need particular old-fashioned
> > server/db sw like Apache, Mysql, etc. or can it be used with more
> > modern alternatives?)
> 
> I disagree with calling Apache 2.4 "old-fashioned" - mpm_event works
> quite well - but it is just good simple CGI.  It can run anywhere Perl
> can.

For an httpd oriented towards dynamic content/"web apps", probably
nginx, but if simple CGI is all it needs, I'd just go for something
fast and light like thttpd.

> It supports MySQL/MariaDB, PostgreSQL, Oracle, and SQLite3.  While I
> prefer pgsql over the others, I'm not sure I would call any of those
> "old-fashioned" either.

Postgres or sqlite would be my preference, with a bias towards the
latter if there's no strong reason not to use it, simply because I
prefer having everything in the filesystem and governed by unix
permissions rather than having to deal with separate databases.

> Assuming this isn't acceptable, what do you consider "modern"?

I think it's fine...

> Unfortunately I have experience with over a dozen issue trackers, so I
> can likely match you to *something* that would work for your
> infrastructure.

...but I am interested in whether you have others that would be worth
considering.

Rich

Re: musl new-year's infrastructure resolutions

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Have you considered github

On Sat, Dec 31, 2016 at 3:38 PM Rich Felker <dalias@libc.org> wrote:

> Here are some things I've really been wanting to get done for a while,
>
> that I/we should try to make happen in the coming months:
>
>
>
> Switching over wiki. The current wiki is essentially unmaintained.
>
> Kylie McClain (Somasis) has setup a clone of the content on a new
>
> git-based wiki that looks good. I still want to understand the
>
> intended workflow for getting changes published, but it's got to be
>
> better than the status quo where account creation doesn't even work.
>
>
>
> Adopting an issue tracker. This requires actually selecting one and
>
> setting up the infrastructure for it. The wiki could possibly be moved
>
> to the same infrastructure. (I want to keep webapp-ish stuff like
>
> wiki, issue tracker etc. off the server that hosts git and release
>
> downloads because anything interactive is a significant attack
>
> surface that puts integrity of code as risk.)
>
>
>
> Enabling git-over-https. This may require switching to a more-capable
>
> httpd or other infrastructure changes on the server.
>
>
>
> Website redesign and move to musl.libc.org. I don't have any concrete
>
> ideas for this yet, but I don't think the current website is at all in
>
> line with musl's maturity, current adoption/deployment, etc.
>
>
>
> Documentation. Existing manual should probably become a public git
>
> repo that contributors can submit patches/PRs for. Putting together
>
> lists of (1) what's outdated in the current one, and (2) what new
>
> content would be most valuable, might be a good place to start and one
>
> that could benefit from community involvement.
>
>

[-- Attachment #2: Type: text/html, Size: 2632 bytes --]

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:
> Have you considered github

My experiences with github have been a constant fight with the tools
rather than having them make things go more smoothly. I don't like the
weight of the web ui (it's very slow on all systems I access it on), I
don't like that it doesn't work properly from mobile browsers (e.g.
line-number links to source files don't work), I don't like how much
you have to click through to get to the history of a given file or to
get a link to a specific version, I don't like that it's impossible to
review large diffs in the web ui (they just timeout loading), etc. I
also don't like everything they do to make it hard to use FF pulls.

Aside from that, using github for your issue tracker seems like a big
commitment/lock-in, if you want issue history to be something stable
and permanent, since I don't see any way to import/export the data.
Whereas with conventional non-hosted-service issue trackers, you have
control of the data and can, at least in principle with a lot of
headache, extract and convert the data to a new tracker if you really
want to.

Rich


> On Sat, Dec 31, 2016 at 3:38 PM Rich Felker <dalias@libc.org> wrote:
> 
> > Here are some things I've really been wanting to get done for a while,
> >
> > that I/we should try to make happen in the coming months:
> >
> >
> >
> > Switching over wiki. The current wiki is essentially unmaintained.
> >
> > Kylie McClain (Somasis) has setup a clone of the content on a new
> >
> > git-based wiki that looks good. I still want to understand the
> >
> > intended workflow for getting changes published, but it's got to be
> >
> > better than the status quo where account creation doesn't even work.
> >
> >
> >
> > Adopting an issue tracker. This requires actually selecting one and
> >
> > setting up the infrastructure for it. The wiki could possibly be moved
> >
> > to the same infrastructure. (I want to keep webapp-ish stuff like
> >
> > wiki, issue tracker etc. off the server that hosts git and release
> >
> > downloads because anything interactive is a significant attack
> >
> > surface that puts integrity of code as risk.)
> >
> >
> >
> > Enabling git-over-https. This may require switching to a more-capable
> >
> > httpd or other infrastructure changes on the server.
> >
> >
> >
> > Website redesign and move to musl.libc.org. I don't have any concrete
> >
> > ideas for this yet, but I don't think the current website is at all in
> >
> > line with musl's maturity, current adoption/deployment, etc.
> >
> >
> >
> > Documentation. Existing manual should probably become a public git
> >
> > repo that contributors can submit patches/PRs for. Putting together
> >
> > lists of (1) what's outdated in the current one, and (2) what new
> >
> > content would be most valuable, might be a good place to start and one
> >
> > that could benefit from community involvement.
> >
> >

Re: musl new-year's infrastructure resolutions

[Alexander Monakov]

On Mon, 2 Jan 2017, Rich Felker wrote:
> > Have you considered github
> 
> Aside from that, using github for your issue tracker seems like a big
> commitment/lock-in, if you want issue history to be something stable
> and permanent, since I don't see any way to import/export the data.

I don't see why you say this; ways to work with issue data programmatically
are documented at https://developer.github.com/v3/ (they use JSON).

For example, this query gives you JSON dump of musl-cross-make issues:

curl -i https://api.github.com/repos/richfelker/musl-cross-make/issues

Importing is also possible.

Alexander

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 09:11:45PM +0300, Alexander Monakov wrote:
> On Mon, 2 Jan 2017, Rich Felker wrote:
> > > Have you considered github
> > 
> > Aside from that, using github for your issue tracker seems like a big
> > commitment/lock-in, if you want issue history to be something stable
> > and permanent, since I don't see any way to import/export the data.
> 
> I don't see why you say this; ways to work with issue data programmatically
> are documented at https://developer.github.com/v3/ (they use JSON).
> 
> For example, this query gives you JSON dump of musl-cross-make issues:
> 
> curl -i https://api.github.com/repos/richfelker/musl-cross-make/issues

Thanks, I wasn't aware of that. I think that makes it a lot more
plausible as a temporary solution for projects that want to move to
their own infrastructure at some point in the future, including
possibly for us, though I think we have other good leads now.

> Importing is also possible.

How do they (or rather do they) prevent you from falsifying posts by
other users in abusive ways?

Rich

Re: musl new-year's infrastructure resolutions

[Solar Designer]

On Mon, Jan 02, 2017 at 11:58:32AM -0500, Rich Felker wrote:
> My experiences with github have been a constant fight with the tools
> rather than having them make things go more smoothly. I don't like the
> weight of the web ui (it's very slow on all systems I access it on), I
> don't like that it doesn't work properly from mobile browsers (e.g.
> line-number links to source files don't work), I don't like how much
> you have to click through to get to the history of a given file or to
> get a link to a specific version, I don't like that it's impossible to
> review large diffs in the web ui (they just timeout loading), etc. I
> also don't like everything they do to make it hard to use FF pulls.

I am no GitHub expert (am not even much of a user), and based on my
(very limited) experience with it so far I agree with your criticism of
it, but FWIW I recently found that "to get a link to a specific version"
you simply need to press "y":

https://help.github.com/articles/getting-permanent-links-to-files/

"When viewing a file on GitHub, you can press the "y" key to update the
URL to a permalink to the exact version of the file you see."

and I actually made use of this on a few occasions already.  There are
other keyboard shortcuts as well.  As the page above says:

"Tip: Press "?" on any page in GitHub to see all available keyboard
shortcuts."

Alexander

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 07:15:35PM +0100, Solar Designer wrote:
> On Mon, Jan 02, 2017 at 11:58:32AM -0500, Rich Felker wrote:
> > My experiences with github have been a constant fight with the tools
> > rather than having them make things go more smoothly. I don't like the
> > weight of the web ui (it's very slow on all systems I access it on), I
> > don't like that it doesn't work properly from mobile browsers (e.g.
> > line-number links to source files don't work), I don't like how much
> > you have to click through to get to the history of a given file or to
> > get a link to a specific version, I don't like that it's impossible to
> > review large diffs in the web ui (they just timeout loading), etc. I
> > also don't like everything they do to make it hard to use FF pulls.
> 
> I am no GitHub expert (am not even much of a user), and based on my
> (very limited) experience with it so far I agree with your criticism of
> it, but FWIW I recently found that "to get a link to a specific version"
> you simply need to press "y":
> 
> https://help.github.com/articles/getting-permanent-links-to-files/
> 
> "When viewing a file on GitHub, you can press the "y" key to update the
> URL to a permalink to the exact version of the file you see."
> 
> and I actually made use of this on a few occasions already.  There are
> other keyboard shortcuts as well.  As the page above says:
> 
> "Tip: Press "?" on any page in GitHub to see all available keyboard
> shortcuts."

Thanks for the tip! Proving once again that the fastest way to get a
solution to a problem is to claim in public that it's not possible...
;-)

Rich

Re: musl new-year's infrastructure resolutions

[Kurt H Maier]

On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:
> Have you considered github

The biggest problem with using github for this is that users will then
be required to have github accounts to file issues.  Good issue trackers
do not put this burden on reporters.

khm

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 10:27:00AM -0800, Kurt H Maier wrote:
> On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:
> > Have you considered github
> 
> The biggest problem with using github for this is that users will then
> be required to have github accounts to file issues.  Good issue trackers
> do not put this burden on reporters.

While I agree it's a burden to require that, it's also a convenience
to be able to use an existing identity (especially if you're given a
choice of which identity provider to use, which is not the case with
github of course) rather than having to create a new account to report
bugs. It would be nice if we could allow that but I don't see the
capaibility in any existing issue trackers.

Rich

Re: musl new-year's infrastructure resolutions

[Kurt H Maier]

On Mon, Jan 02, 2017 at 01:36:52PM -0500, Rich Felker wrote:
> While I agree it's a burden to require that, it's also a convenience
> to be able to use an existing identity (especially if you're given a
> choice of which identity provider to use, which is not the case with
> github of course) rather than having to create a new account to report
> bugs. It would be nice if we could allow that but I don't see the
> capaibility in any existing issue trackers.

JIRA and Mantis support OAuth, Redmine and RT support OpenID, Redmine
and JIRA support Shibboleth federation, and RT can be used by reporters
entirely without authentication (via email). Bugzilla can be made to
support OpenID.  None of these systems are particularly lightweight.

I dearly hope people have some great suggestions to contribute, and I
eagerly await to see what musl winds up with -- I have a couple projects
that are in need of issue trackers and to date we've been doing informal
things or abusing our gitlab installation, and I'm not truly pleased
with either answer.  

khm

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 10:52:38AM -0800, Kurt H Maier wrote:
> On Mon, Jan 02, 2017 at 01:36:52PM -0500, Rich Felker wrote:
> > While I agree it's a burden to require that, it's also a convenience
> > to be able to use an existing identity (especially if you're given a
> > choice of which identity provider to use, which is not the case with
> > github of course) rather than having to create a new account to report
> > bugs. It would be nice if we could allow that but I don't see the
> > capaibility in any existing issue trackers.
> 
> JIRA and Mantis support OAuth, Redmine and RT support OpenID, Redmine
> and JIRA support Shibboleth federation, and RT can be used by reporters
> entirely without authentication (via email). Bugzilla can be made to
> support OpenID.  None of these systems are particularly lightweight.

JIRA is everything I dislike about github's UI, but far worse, at
least from my experience using it on Atlassian/bitbucket. So it's
pretty much out of the question.

Mantis doesn't seem so bad as a user but I have no idea how bad it is
under the hood. Redmine looks kinda nice and Alpine uses it.

Re: OAuth and OpenID, I get the impression that OpenID is dead, so
support for it probably isn't useful. At least Google and likely other
providers have dropped it, right?

Rich

Re: musl new-year's infrastructure resolutions

[Kurt H Maier]

On Mon, Jan 02, 2017 at 02:16:24PM -0500, Rich Felker wrote:
> 
> JIRA is everything I dislike about github's UI, but far worse, at
> least from my experience using it on Atlassian/bitbucket. So it's
> pretty much out of the question.

I've administered JIRA; it is a bureaucratic nightmare that requires a
full-time person to manage its insane workflows.  But I tried not to let
my personal feelings leak into the summary.  I am glad to hear it is
Ruled Out. 

> Mantis doesn't seem so bad as a user but I have no idea how bad it is
> under the hood. Redmine looks kinda nice and Alpine uses it.

Redmine is a very typical Ruby on Rails application.  It works as
advertised but requires familiarity with that ecosystem to install and
operate.  Mantis is a php application with all of the typical travails
of php.

> Re: OAuth and OpenID, I get the impression that OpenID is dead, so
> support for it probably isn't useful. At least Google and likely other
> providers have dropped it, right?

OpenID as we knew it is dead; it has been and/or is being replaced with
a successor called 'OpenID Connect' which works almost nothing like
OpenID used to.  It's a regrettable branding collision, but it at least
adds proper authentication to OAuth2, which really only gets
authorization right.

In my personal opinion, nobody's got any of this stuff "right" yet.  RT
and Bugzilla work around it by either relying entirely on email
address as identity or by having a siloed inbuilt id/password combo.

khm

Re: musl new-year's infrastructure resolutions

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/01/17 14:06, Kurt H Maier wrote:
> On Mon, Jan 02, 2017 at 02:16:24PM -0500, Rich Felker wrote:
>> Mantis doesn't seem so bad as a user but I have no idea how bad
>> it is under the hood. Redmine looks kinda nice and Alpine uses
>> it.
> 
> Redmine is a very typical Ruby on Rails application.  It works as 
> advertised but requires familiarity with that ecosystem to install
> and operate.  Mantis is a php application with all of the typical
> travails of php.


That's a very diplomatic assessment of Rails.

I administer multiple Rails applications - GitLab, a custom CMS, one
of the eCommerce packages, and a full Web application that was
developed in house.  I cannot believe how much of a resource drain
they are, even having gone through the pain of optimising the entire
stack.  I think the smallest RAM footprint I've ever seen out of Rails
is 450 MB resident.

This isn't even a Ruby problem; I have seen Sinatra using under 50 MB.

For a large Redmine install with a lot of users and some concurrency
(i.e. multiple people doing /something/ at the same time), I wouldn't
use a box with less than 2 GB RAM and dual-core.  And that's pushing it.

Look, I used to *be* a Rails developer.  I like the rapid prototyping
that it allows and I even *still* use it for that.  But it isn't
something I would ever choose to run in production.

- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYattiAAoJEMspy1GSK50UIMIP/RKQN5hiA+cigy7eZwMY3YEx
+eps9jp0uBSR4LuHRtKf06HhTgsfwTuy+/NRE2rdykSU2lXhh+QoedsclQ1Ga1Zr
/gXGDMBjPvhkH8QDzxO0Um8DuIm/sDuz2ByysxFBX6k4/Hhqc+esodM+j6adyY1g
Zsx8lJWXW1DXu2J1/Tp/uAKUpdRY6Xdygq76z9zfzgH6uJ3ia0pb7lcYn+Sgzsdb
rnAf1jr/BqrDrSsEKbcNSB2SLW26k868GhsY7bKAF3FY2q4CAHatnc2bfM/qBWz8
8IOGjzUqk3mI+6JJgFq+uIbeXrc0Jpa+J7igEwOEYaHmNgjfaCciWt558/XjfnmM
ndu8KkO5TaRz584olVpWbzkF0+YgDsygIOJx19GS7I5Okg/B9Xs5t/7+rTetshs/
qZvU8P+wiIeTi69c75ByrnZRwICoX1KL6I9dAfOJtjPT51Xb29X8MXmN48moZBYG
5oXxaaafqU9D7nRAArzgphZarJR7eVSfA7MbH49539kR4+wHJIXvC2cYd5IgfiSt
Wm9T/D1OkO0MaXco0YXRfM6bVJh4uWU89FggPj2yqWStL/GNH5fxDUp8ntzvdy7w
aw58+ObcSOJpVgpm/pfRJJGk2Jrz+SmoTC6PFEIM3KFu3Ak1wNehoDllsEIfrTA/
/1J2PsOAxZq05VidsD5E
=98Mf
-----END PGP SIGNATURE-----

Re: musl new-year's infrastructure resolutions

[Kurt H Maier]

On Mon, Jan 02, 2017 at 04:59:49PM -0600, A. Wilcox wrote:
> 
> That's a very diplomatic assessment of Rails.
> 

That was my intention.  I'm also not a fan of Rails, but its evangelists
are widespread and well-paid and I didn't want to start an off-topic
argument with any of them.

khm

Re: musl new-year's infrastructure resolutions

[Matias A. Fonzo]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

Hello Rich,

On Mon, 2 Jan 2017 13:36:52 -0500
Rich Felker <dalias@libc.org> wrote:

> On Mon, Jan 02, 2017 at 10:27:00AM -0800, Kurt H Maier wrote:
> > On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:  
> > > Have you considered github  
> > 
> > The biggest problem with using github for this is that users will
> > then be required to have github accounts to file issues.  Good
> > issue trackers do not put this burden on reporters.  
> 
> While I agree it's a burden to require that, it's also a convenience
> to be able to use an existing identity (especially if you're given a
> choice of which identity provider to use, which is not the case with
> github of course) rather than having to create a new account to report
> bugs. It would be nice if we could allow that but I don't see the
> capaibility in any existing issue trackers.
> 

Have you taken a look at http://fossil-scm.org ?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: musl new-year's infrastructure resolutions

[Rich Felker]

On Mon, Jan 02, 2017 at 04:10:31PM -0300, Matias A. Fonzo wrote:
> Hello Rich,
> 
> On Mon, 2 Jan 2017 13:36:52 -0500
> Rich Felker <dalias@libc.org> wrote:
> 
> > On Mon, Jan 02, 2017 at 10:27:00AM -0800, Kurt H Maier wrote:
> > > On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:  
> > > > Have you considered github  
> > > 
> > > The biggest problem with using github for this is that users will
> > > then be required to have github accounts to file issues.  Good
> > > issue trackers do not put this burden on reporters.  
> > 
> > While I agree it's a burden to require that, it's also a convenience
> > to be able to use an existing identity (especially if you're given a
> > choice of which identity provider to use, which is not the case with
> > github of course) rather than having to create a new account to report
> > bugs. It would be nice if we could allow that but I don't see the
> > capaibility in any existing issue trackers.
> 
> Have you taken a look at http://fossil-scm.org ?

From what I can tell it seems to want to replace git rather than being
able to integrate with git, which seems like something of a
show-stopper.

Rich

Re: musl new-year's infrastructure resolutions

[Matias A. Fonzo]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Mon, 2 Jan 2017 14:18:31 -0500
Rich Felker <dalias@libc.org> wrote:

> On Mon, Jan 02, 2017 at 04:10:31PM -0300, Matias A. Fonzo wrote:
> > Hello Rich,
> > 
> > On Mon, 2 Jan 2017 13:36:52 -0500
> > Rich Felker <dalias@libc.org> wrote:
> >   
> > > On Mon, Jan 02, 2017 at 10:27:00AM -0800, Kurt H Maier wrote:  
> > > > On Mon, Jan 02, 2017 at 06:39:37AM +0000, Khem Raj wrote:    
> > > > > Have you considered github    
> > > > 
> > > > The biggest problem with using github for this is that users
> > > > will then be required to have github accounts to file issues.
> > > > Good issue trackers do not put this burden on reporters.    
> > > 
> > > While I agree it's a burden to require that, it's also a
> > > convenience to be able to use an existing identity (especially if
> > > you're given a choice of which identity provider to use, which is
> > > not the case with github of course) rather than having to create
> > > a new account to report bugs. It would be nice if we could allow
> > > that but I don't see the capaibility in any existing issue
> > > trackers.  
> > 
> > Have you taken a look at http://fossil-scm.org ?  
> 
> From what I can tell it seems to want to replace git rather than being
> able to integrate with git, which seems like something of a
> show-stopper.
> 

Fossil has everything you are looking for, even is easy to setup, of
course is another SCM.  Just in case:

  http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki


Best regards,
Matias

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: musl new-year's infrastructure resolutions

[Laurent Bercot]

>Fossil has everything you are looking for, even is easy to setup, of
>course is another SCM.

  FWIW, I was looking for a SCM a couple years ago, and I tried out 
fossil,
drawn by its simplicity and build cleanliness.

  Unfortunately, this simplicity comes at the expense of modularity or 
even
basic layering of software.
  You cannot configure the Web interface out. There is no CLI for 
managing
project permissions, you *have to* use the Web interface for that. I did
not look further, because that was an absolute deal breaker for me.

--
  Laurent