Re: musl new-year's infrastructure resolutions

[Rich Felker <dalias@libc.org>]

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