2.14 release, or GOP now?

[Graham Percival]

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?