Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Jan 2017 16:37:04 -0600
From: "A. Wilcox" <>
Subject: Re: musl new-year's infrastructure resolutions

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 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
Version: GnuPG v2


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.