From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10843 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl new-year's infrastructure resolutions Date: Sun, 1 Jan 2017 21:31:39 -0500 Message-ID: <20170102023139.GX1555@brightrain.aerifal.cx> References: <20161231233747.GV1555@brightrain.aerifal.cx> <58698490.4040904@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1483324314 32735 195.159.176.226 (2 Jan 2017 02:31:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2017 02:31:54 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10856-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 02 03:31:50 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cNsPe-0007yV-1w for gllmg-musl@m.gmane.org; Mon, 02 Jan 2017 03:31:50 +0100 Original-Received: (qmail 1470 invoked by uid 550); 2 Jan 2017 02:31:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1452 invoked from network); 2 Jan 2017 02:31:52 -0000 Content-Disposition: inline In-Reply-To: <58698490.4040904@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10843 Archived-At: 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