lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: state of the release: the Good, the Bad, and the Ugly


From: Graham Percival
Subject: Re: state of the release: the Good, the Bad, and the Ugly
Date: Thu, 27 May 2010 13:28:13 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, May 27, 2010 at 12:06:47PM +0200, Valentin Villenave wrote:
> On Wed, May 26, 2010 at 3:39 PM, Graham Percival
> <address@hidden> wrote:
> > In the "avoid losing info" side of things, although I'm cautiously
> > optimistic that any *new* info won't be lost, we still have a number
> > of lost items from the past few months, and no volunteers to go on an
> > archival dig.  I know that archeology isn't as sexy as Indiana Jones
> > makes it out to be, but it's still an important job.
> 
> On the archeological side, I can probably help. Give me about 3 weeks
> and I'll be a /lot/ more available for LilyPond tasks.

That would be nice.

> > We have 10 issues with patches attached; 3 of them fixing Critical
> > issues.  Some people might view this as a positive thing -- hey, we
> > have people sending fixes! -- but I'm counting this as "ugly" because
> > it means that we're not supporting each other enough.  I'd like to see
> > a more effort put towards reviewing and finishing patches.
> 
> This is one of the few areas left where we still rely upon Han-Wen a
> lot, and do not (AFAICS) a properly-organized team as we (kinda) have
> wrt bugs, frogs, docs etc.

Actually, Han-Wen has had the "final say" on fewer patches than
either Neil or Carl in the past four months.  It's been getting
more distributed, which is a good thing.

> Which brings up the question of the tools we use:

It's not a question of tools.  It's just a question of interest
and motivation.

> - [Patch]-marked mails on -devel don't work,
> - "Patch"-tagged issued on the tracker don't seem to work either...

Actually, they *do* work.  Marek has been adding patches to the
tracker, and so far I've "discovered" 3 patches that I'd
completely forgotten about.  We have the paper trail, so we're not
losing patches, so I can remind people to look at them.

> > The Contributor's Guide is supposed to handle the initial training of
> > helpful people (or, at the very least, separate the seriously-helpful
> > from the non-seriously-helpful)... but this doesn't help when certain
> > parts are out of date.  Anybody feel like working on this?  If not, it
> > can wait until I'm preparing for GOP -- but that means turning away
> > genuine offers of help for development tasks for the next 2-4 months.
> 
> I've been reading (actually, discovering) the CG over the past few
> weeks, and I have to say it seems quite complete and up-to-date to me.
> Unfortunately it seems most people prefer to be told what to do
> instead of RTFCG.

False.  The recent "checking to see if a patch breaks any
regtests" clearly demonstrated that: first, the material was hard
to find, and second, the material was *inaccurate*.  It was
written based on the "make help" instructions, which most people
know (by "oral tradition") are hopelessly out of date and should
be ignored, but the person working on that part of the CG thought
they could be trusted.  In other cases, such as doc work, the
material *is* there but it hard to find.

It's easy to flip through the CG and say "yeah, I recognize this
stuff"... but when you're actually mentoring a new contributor,
you suddenly discover huge gaping holes.

In particular, look at the Issues and LSR chapters.  Each section
is something like 3-5 pages long.  Are they complete and
up-to-date?  I very much doubt it.  Read over those carefully,
make fixes as appropriate, and let me know if you claim that they
are complete.  I'll then find three inaccuracies or omissions.

I'm not just picking on Issues and LSR because those are things
that you can review.  I'm picking on them because we'll do GOP in
a piecemeal approach, beginning with "simple tasks" (as defined on
the "help us" page).  We'll begin training people to do anything
they can do without git.

Cheers,
- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]