A Proposal: EOL 4.1, Branch 4.2, Start 4.3
sebas at kde.org
Sat Dec 6 10:00:40 CET 2008
On Friday 05 December 2008 12:48:59 Tom Albers wrote:
> > > Communicate that bugfixing is still a top priority until 4.2.0 is
> > > released.
> > You said it yourself: bug fixing is top priority, why make it more
> > difficult? I am against prematurely thawing trunk as quite a few
> > developers will shift from bug fixing into feature development (I can
> > see myself doing this) even if they know they will let some bugs get
> > into 4.2 that could have been avoided. Trunk should remain in whatever
> > mode that will benefit the top priority--if feature additions are top
> > then it's thawed, if it's bug fixing then it's frozen.
> Yeah, that's what I was thinking until recently, after that I realised that
> some applications do not contain obvious bugs and that they want to
> continue with features. Also you can also see the support for the 'always
> summer in trunk' idea within the community, I think we should not ignore
> So, although I do agree with you for some part, I would like to try this
> now to see how it goes. If it really does not work, we should reconsider it
> for the 4.3 release, if the results are ok, then we are one step closer to
> the always summer in trunk idea.
The summer in trunk idea comprises more than just branching earlier. I'm
afraid we're risking 4.2 when we try to pull this off now.
To me it sounds like a half-assed approach to the seasons approach. "Summer in
Trunk" has clearly not come out of the last discussion on core-devel as a
winner, much more so a stepped, 'seasons' approach ("always fall in trunk -
but never winter)" was the most popular model). I'm guilty of not following up
on this, though. :/
We're now all pretty firmly in bug-fixing mode, changing the base under the
feet of the people (which is essentially what we're doing when branching) now
without a lot of warnings would, I think reduce the amount of attention 4.2
bugs get. Communicating that people should focus on 4.2 bugs won't really work
without a cunning plan, the "Improving Communication" thread does give us
pointers, but I don't think we're there yet.
IMO, we should branch at -rc1, not earlier.
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
More information about the release-team