On 7/10/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> Erik Huelsmann wrote:
> > I'm not seeking to accuse anybody, but feel I should speak up about
> > the way I'm feeling.
> >
> > Ever since 1.3, I feel like we're more and more unable to get releases
> > out the door (within a reasonable time after branching).
> >
> > I haven't identified any reasons why this might be happening or even
> > what to do about them. That is the reason of this mail: do others feel
> > the same? Do you have ideas why it is happening? Do you have ideas how
> > to prevent it?
>
> I believe it is simply a matter of our release manager not having time.
> Not that I blame him, it's just that we have no paid, full time release
> manager, so we get releases when he has time to make them.
>
> He hasn't had time lately due to other, higher priority (and rightly so)
> commitments.
>
> >
> > One possible reason is that we have too many changes per release: most
> > of which go largely untested as long as they're on trunk, getting
> > first exposure on a release branch. When many changes/new features are
> > exposed this way, stabilization takes a long time. This ofcourse isn't
> > in any way 'the truth'. I hope others have thought about it too.
>
> Sorry, I don't believe this at all. All the time we've spent has been
> waiting for RC's to be rolled and getting signatures, not waiting for
> features to be fixed.
Well, from 1.3, I remember the python bindings memory management
needing fixes after branching (and before RC1). This time, we have -
at least - the bdb 4.4 fixes we've been waiting for.
In my opinion neither was an *RC1* show stopper though, once the cause
was identified: we could have released with the first bdb 4.4 fix and
worked on the bdb-4.4-real-fix while collecting test results for RC1
IMO, since there was no dataloss, only segfaults (at program
shutdown!) which required bdb recovery, but that's built-in now...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 08:57:59 2006