We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14.
There's no problem with that, of course -- this is a volunteer project, and we have no strict schedule. If we want to work on non-Critical issues, that's fine. Along those lines, I'm wondering if it's worth starting GOP, the Grand Organization Project, now. This would most likely make a 2.14 release in 2010 impossible, but it looks like we're heading in that direction anyway. I'm sick of always saying "yes, that's a serious issue that we should discuss, but please wait until after 2.14 so that we don't spend all our development time talking instead of writing+reviewing patches". If we don't want to be in "release crunch" mode, then I don't want to be the wet blanket. There are two parts to GOP: 1) recruiting+training new users, and 2) policy decisions. I've prepared an agenda for the latter; you can read it here: http://lilypond.org/~graham/gop/policy.html I'll copy&paste the text below in case anybody would prefer to see it in text form. Cheers, - Graham LilyPond GOP - Policy decisions We've been postponing a bunch of policy decisions for the past few years. Let's discuss them as part of GOP. To avoid everybody talking about everything at once, I've made an agenda. If you want something added, email me. Please note that the presence of an item in this list does not mean that I personally think that anything needs to change. In fact, I consider at least one of these topics to be silly and completely impractical. However, I know that at least one developer thinks that it's worth discussing, so I think we should treat it seriously. I propose discussing one topic each week, once GOP starts. Yes, it will take months to go through this list -- but I don't think that we should completely abandon all productive work while we discuss policy. "One per week" seems like a decent balance of productive work vs. policy administration. There are two items not displayed here; these are questions that were posed to me privately, and I do not feel justified in discussing them publicly without the consent of the person(s) that brought them up. They will initially be discussed privately on the lilypond-hackers mailing list -- but the first question will be "do we absolutely need to do this privately", and if not, the discussion will take place on lilypond-devel like the other items. 1. Patch reviewing At the time of this writing, we have 21 (known) patches waiting for review. Some from main developers; some from new developers. We desperately need more people helping with lilypond, but ignoring patches is the best way to drive potential contributors away. This is not good. I have some proposals to mitigate this problem. 2. Lessons from the 2.14 release; future release policy What went well; what went badly? (how) should we change any policies pertaining to releases? Should an undocumented new feature count as release-blocking? 3. Hackers A 4. Hackers B 5. Code style New contributors sometimes struggle to follow our indentation and code style -- this is especially difficult when parts of our existing source code doesn't have a consistent style. This is problematic... we want new contributors to be struggling with the lilypond architecture, not playing games in their text editors! (ok, we don't actually want them to be struggling with lilypond internals... but given the current state of the CG, it's understandable, and at any rate it's still better than struggling with code style) Speaking academically, C++ code style is a "solved problem". Let's pick one of the existing solutions (probably either astyle, uncrustify, or emacs), and let a computer deal with this. I've been investigating this, and will have a report ready. 6. Git repository(s) We currently have a web/ branch in our main repo; this seems misleading to new developers. More generally, should we have branches that aren't related to the master? i.e. should we restrict a git branch to code which is an actual "branch" of development? Also, some of our code (notably the windows and osx lilypad) isn't in a git repository at all. We can add new repositories very easily; should make repositories like git://git.sv.gnu.org/lilypond/gub.git git://git.sv.gnu.org/lilypond/lilypad.git git://git.sv.gnu.org/lilypond/misc.git ? More information here: http://code.google.com/p/lilypond/issues/detail?id=980 7. Roadmap of future development Many projects have a roadmap of planned (or desired) future work. Should we use one? If so, what should go on it, bearing in mind our volunteer status? Is there any way of having a roadmap that isn't vaporware? 8. Official links to other organizations? There's something called the "software freedom conservancy", and in general, there's a bunch of "umbrella organizations". Joining some of these might give us more visibility, possibly leading to more users, more developers, maybe even financial grants or use in schools, etc. 9. Mailing lists We currently have a mix of official GNU mailing lists and lilynet lists. Is there a strong rationale for having separate mailing list servers? Why not pick one place, and put all our lists there? (or at least, all "permenant" lists?) 10. Issue tracking with google code We use the google issue tracker, but this means that we are relying on a commercial entity for a large part of our development. Would it be better (safer in the long run) to use the savannah bug tracker? 11. Patch review tool Reitveld is inconvenient in some respects: it requires a google account, and there's no way to see all patches relating to lilypond. Should we switch to something like gerritt? http://code.google.com/p/lilypond/issues/detail?id=1184 12. Subdomains of *.lilypond.org Unless Jan has a really weird DNS hosting setup, there are no technical barriers to having names like lsr.lilypond.org, frog.lilypond.org, or news.lilypond.org. Is this something that we want to do? _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
