[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 2 Jan 2017 11:58:32 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl new-year's infrastructure resolutions
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@...c.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.
> >
> >
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.
