Re: stable/2.12 and tagging of tarballs

[Jan Nieuwenhuizen]

Op dinsdag 09-06-2009 om 07:12 uur [tijdzone -0700], schreef Graham
Percival:

> Dunno.  Is this an automatic tagging?  I'm still trying to figure
> out what branch/tags are done automatically by GUB.

Release tags are inserted by GUB.  Branching is done manually,
developers must decide to what branch to commit, the GUB Meister
must tell her GUB from what branch to build, eg master or stable/2.12

> Sure there is.  If we don't make any later releases, then we have
> a final one!  :)

Exactly :-)  But until that last one, it is nice to have a place
to commit stable fixes and to release from.

> Given the lack of people interested in maintaining backports, the
> proposal is that we just say "wait for 2.14".

Yes, well that's a decision you have to make.  I much rather
see only a few stable point releases and 2 stables a year.  How did
we get up to 2.10.33 anyway?

> Yes, IIRC early Feb.

Any idea of a commit, ie, anything missing from the current
stable/2.12?

> > I propose to release a buildable 2.12.3 tarball, and to have name a
> > stable and a development branch.  Numbering isn't all that interesting,
> > but linux also has that: you need [at least] two [more or less] active
> > branches if you are willing to do some kind of sane release management.
> > IMHO, of course :-)
> 
> I disagree.  I think that having 2.12, followed by 1-3 months of
> bugfix updates, then a gap of 4 months, then 2.14, works fine.
> The "gap" is as far as normal users are concerned.  Developers
> will have 2.13 releases during that "gap".

This is what might happen in practice, but this is not what you
should be planning.

While planning for a stable release, say 2.14, there is a stabilizing
period in which only bugfixes are done, and possibly [major] 
documentation updates.  If you're unlucky, that period can take
two months or so.

Then you branch stable/2.14, release 2.14.0 from that branch.  During
this period of stabalizing, there is *no* development branch and
a major focus on fixing, sometimes silly nitpicky bugs.  Chances
are that as soon as stable/2.14 is branched, developers want
to commit risky new stuff to master.

When problems are found, usually a developer will 

  * verify if it's still a problem with master/development
  * fix it in master, esp helpful for simple fixes is to
    add a marker BACKPORTME to the commit message
  * git cherry-pick it into stable herself

I talked with Han-Wen about 2.10.  The reason that we got up
to 2.10.*33*, is that with git, doing stable bugfix releases
is almost painless.  Very little effort.  We have small,
contained patches/commits, that can be very easily cherry
picked into stable.  Now with CVS, it was hairy.  This
is a very nice and cheap way of supporting users.  Users
should not run development releases, but having fast-turnover
regular stable bugfixing updates is *very* *very* nice.

> This is mostly what we've been doing anyway -- sure, 2.10 reached
> .8 or .10, but at some point, we all said "not worth backporting
> stuff" and we ignored it for a year or so.  All updates were 2.11.

Sometimes you may not open development (and possibly not even
branch stable) until .3 or .4 say; if you know or expect issues
and want developers to focus on making stable really stable
instead of running of to the development branch.  But ideally,
all stable point releases are cherry picks from bugfixes in
master.

> I'm just proposing that we make this "laziness" official.  To
> counteract the gap between stable releases, we make many more
> stable releases -- 3-4 releases each year.  If I hadn't been in
> Singapore, we'd be working on 2.15 right now, having already
> released 2.14, finished the stable maintenance, and moved into
> 2.15.

Right, that's another point.  Planning for often and early major
stable releases is good.  My experience tells me, however, that
unless you have a very rigid pulse, schedules tend to slip.
If you're very unlucky, they can easily slip 6months or a year.
This is free software, anything can come up.  So it is wise
to be able to help users with cheap, quick stable point releases,
and have all the time you need in practice to make the next
major stable release.

> The plan right now is:
> - clarify the maoing git repos
> - finish the CG (other than the programming chapter)
> - check with Han-Wen about updating libs (pango, fontforge,
>   mftrace, whatever)
> - start 2.14 release procedures.

Great.  In the mean time we should

  - release a 2.13.3 that builds

> We'd potentially release 2.14 by the end of this month.
> Francisco: no, I haven't forgotten about giving notice to the
> translators, and giving them a week or two to finalize stuff.

That would be nice.  However, if it is going to August 1 again
(or later :-), I suggest releasing another 2.13.4 with some
fixes.

New stable point releases that users can upgrade to without
much risk are a nice way to generate more traffic/attention
to the website, keep users more involved etc.  You can
update the website to mention what has been done and
build the community.  If nothing happens in the half
year between major stables, it may become awfully quiet.
At least, that's the way we used to think about it.

Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org