Rocky Burt wrote:
> On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote:
> I've only ever worked on one open source project where I was not
> supposed to backport my fixes to the maintenance release branches and
> that is Plone. For Plone we have someone responsible for back-portting
> that stuff in bulk. It makes his job harder if we manually back-port
> fixes as then he has to be more selective with the patches he backports.
> Thanks Hanno!
> But my point is it is pretty standard behaviour to have to backport
> fixes to all actively maintained branches.
You got it backwards ;) I only forward-port any changes from older
branches to the more recent ones, but never do any backports. The reason
I do this is because before this, Plone developers tended to only fix a
bug on the trunk or the latest stable release. My hope was that by
lowering the bar by only requiring developers to fix a bug on the oldest
maintained release branch, more people would actually do this and in
fact I think this strategy has worked out. This works in conjunction
with our quite well-maintained bug-tracker where bugs get assigned to
the release they should be fixed in by a small group of people.
But two things to keep in mind that differentiate Plone from Zope3 in
this regard are, that most of the fixes in Plone are template issues or
minimal changes that apply cleanly on the newer branches and when they
don't or I do not understand them I ask the bug fixer to forward port
it. Also maybe more importantly we only really have three changing
packages (CMFPlone, ATContentTypes and Archetypes) which do not require
things to be merged from one to another - we havn't yet started to move
things around ;)
For Zope3 the only sensible option IMO is, as others already mentioned
it, to have a fix-on-the-oldest-maintained-branch-first bug fixing
policy which requires to forward port these fixes to all branches up to
Zope3-dev mailing list