Re: stable/2.12 and tagging of tarballs

[Graham Percival]

On Tue, Jun 09, 2009 at 08:07:57AM -0600, Carl D. Sorensen wrote:
> 
> On 6/9/09 7:56 AM, "Jan Nieuwenhuizen" <address@hidden> wrote:
> 
> > 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 don't want to speak for Graham, but I think the original proposal was made
> to avoid development effort spent in backporting.  But I can't think of a
> good way to avoid backporting if it's desired to have bugfixes on the stable
> release.

That's true.  However, I chose to avoid having bugfixes on the
stable release.  It's a simple question of resource allocation --
how can we make best use out of the limited resources?

Who here is capable of backporting?  I don't just mean doing the
git stuff, but evaluating what's worth backporting, making sure
that those patches don't wreck anything or depend on anything
else, etc.  Han-Wen, Jan, Joe, John, Werner... maybe Carl,
Reinhold, and a few other people.  What's the common factor?
Other than technical excellent and a love of open source, these
people are all _very_ busy.

I'm more than capable of recruiting and training people to do
various tasks -- documentation, LSR editing, checking the
regtests, etc -- but I *don't* think that I can take a newbie and
turn them into a backporting person in a few weeks.


Let's look at the problems in the 2.12.2 release, shall we?
1. the tarball didn't match the actual build from git.  Whoops,
  that sucks... but the release obviously *did* build, so if
  we're more careful about tarball generation, then that won't
  be a problem.
2. broken Japanese translation.  If 1 wasn't a problem, then this
  wouldn't matter (the release obviously _did_ build).  This could
  have also been avoided by not adding it at the last moment; we
  should have waited for 2.13 for this.
3. no gcc 4.4 patches.  That's a rare occurrence; I don't know if
  gcc screwed up before 4.3, or screwed up in 4.4, but this
  shouldn't be a problem in the future.
4. ... IIRC there was something else, but I forget what it was at
  the moment.


I'm entirely comfortable telling people "wait for 2.14; it'll be
out in 3 months" if these problems were discovered two weeks after
2.13 was started.  For package mainteners, we can point them at
the patches for #3.  As long as the tarball builds on the system
requirements we list, I think we should just tell people to wait,
and spend our time working on that new release.

Cheers,
- Graham