13.4.3 Policy decisions
There are a number of policy decisions – some of them fairly important – which we have been postponing for a few years. When GOP begins, we will start discussing them.
Note: The fact that we are not arguing about them right now is not, I repeat not, an indication that we do not feel that these issues are not important. It is simply that if we began talking about them now, it would postpone the 2.14 release for a few months.
Note that the presence of an item on this list does not mean that everybody thinks that something needs to be done. Inclusion in this simply means that one developer thinks that we should discuss it. We are not going to filter this list; if any developer thinks we should discuss something, just add it to the bottom of the list. (the list is unsorted)
Once GOP starts, the list will be sorted into a rough agenda. We will probably introduce one topic each week – yes, it will therefore take months to get through everything, but we must balance productive work vs. policy administration. If we find that we settle questions faster (or slower) than predicted, we will of course change the speed of new topic introductions.
There are some item(s) 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.
In most policy discussions in lilypond over the past few years, the first half (or more) is wasted arguing on the basis of incorrect or incomplete data; once all the relevant facts are brought to light, the argument is generally resolved fairly quickly. In order to keep the GOP discussions focused, each topic will be introduced with a collection of relevant facts and/or proposals. It is, of course, impossible to predict exactly which facts will be relevant to the discussion – but spending an hour or two collecting information could still save hours of discussion.
Note: The estimated time required for "prep work", and the following discussion, has been added to each item. At the moment, there is an estimated 30 hours of prep work and 140 hours of discussion.
- Patch reviewing:
At the time of this writing, we have 23 (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.
(prep: 2 hours. discuss: 10 hours)
- 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?
(prep: 1 hour. discuss: 15 hours)
- lilypond-hackers mailing list:
Should we have a private mailing list for senior developers? If
so, who should be on it?
(prep: 2 hours+3 weeks. discuss: 10 hours)
- Hackers B:
- 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.
(prep: 5 hours. discuss: 15 hours)
- 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
(prep: 2 hours. discuss: 10 hours)
- 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?
(prep: 1 hour. discuss: 5 hours)
- 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.
(prep: 2 hours. discuss: 5 hours)
- 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 "permanent" lists?)
(prep: 1 hour. discuss: 5 hours)
- 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?
(prep: 1 hour. discuss: 5 hours)
- 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
(prep: 5 hours. discuss: 15 hours)
- 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?
(prep: 1 hours+2 weeks. discuss: 5 hours)
- Authorship in source files:
Our documentation currently does not attempt to track individual
authors of each file, while our source code makes a confused and
jumbled attempt to track this. A number of guidelines for F/OSS
projects explicitly recommends _not_ tracking this in individual
files, since the code repository will track that for you.
(prep: 2 hours. discuss: 15 hours)
- Clarity for sponsorships:
We currently do not advertize bounties and sponsorships on the
webpage. How much advertising do we want, and what type?
Should we change the "structure" / "framework" for bounties?
(prep: 2 hours. discuss: 10 hours)
- Separate branches for active development:
it might be good to have everybody working on separate
branches. This complicates the git setup, but with sufficient
logic in lily-git.tcl, we can probably make it transparent to
newbies. However, we’d need a reliable person to handle all the
required merging and stuff.
(prep: 2 hours. discuss: 10 hours)
- Precise definition of Critical issues:
at the moment, a stable release is entirely dependent on the
number of Critical issues, but there’s some questions about
precisely what a "Critical issue" should be. We should clarify
this, in conjunction with a general discussion about how often we
want to have stable releases, how permissive we want to be about
patches, etc etc.
(prep: 1 hour. discuss: 5 hours)
- When do we add regtests?:
There is a discrepancy between our stated policy on adding
regtests, and our actual practice in handling bugs and patches.
Clarify.
There is also a wider question how to organize the regtests, such as where to put interesting-console-output regtests, including stuff like lilypond-book and midi2ly in a sensible manner, and possibly including regtests for currently-broken functionality.
(prep: 2 hours. discuss: 5 hours)