Martijn Faassen wrote:
Thanks for doing this work, Christian. I'm in favor of going for Zope
3.4 on a timely basis.
I wouldn't mind that.
Concerning the delay of Zope 3.3, I think we should consider whether
we're not too perfectionistic.
On the one hand core developers seem to be happy to use the trunk for
development projects, and on the other hand we demand a lot of work
doing bugfixes in a release, up to the point where we delay the release
itself. That's a bit paradoxical - evidently the bugs aren't harmful
enough to harm these developers much most of the time, but at the same
time we consider them extremely harmful if they should appear in a release.
I've come to wonder the same thing.
What about a policy where we fix bugs until the release date, and then
on the release date, we actually release? Any bugs that are still in it
are going to go with it.
Yes, provided we have a release branch babysitter who will spit out new
bugfix releases once a final release has been made. I'd be willing to do
this for Zope 3.2, provided people actually do their bugfixes there.
Anyway, if the Gnome project can do time-based releases *on the date* we
should be able to do it too.
I bet the Gnome project has members who are actually paid to do this
kind of release management, though. That doesn't mean we should postpone
a final release over and over again, just because we don't have the
resources. In fact, because we don't have the resources, we should
release a final anyway and catch up with bugs in, well, bugfix releases :).
Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
