On Thu, May 27, 2010 at 12:06:47PM +0200, Valentin Villenave wrote: > On Wed, May 26, 2010 at 3:39 PM, Graham Percival > <gra...@percival-music.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
