Jim Fulton wrote:
I would go further.  I would not unfreeze the trunk until until we've
 cleaned up all open bugs, either by fixing them or rejecting them.


Why, do you think we should allow old bugs to languish forever?

I think this would be a bad thing to do after every release, though you could do it for a release once every while, I guess. Volunteer effort in one area doesn't transfer necessarily to volunteer effort in another area, though. You'd block contributors who were interested in moving the trunk forward, or force them to do it on their own branch.

I think such a larger audience needs to grow organically and has fairly little to do with the bugfixing issues.

We disagree.

Okay, to make it clear:

a) I believe that getting timely releases with new features out can help grow the audience for Zope.

b) I believe that having high-quality .0 releases can grow the audience for Zope.

c) I believe Zope 3 trunk at arbitrary points in time is already a fairly high-quality release even without significant bugfix work being done, thanks to the focus on quality in the development process. People developing their applications against the trunk appear to share this opinion.

d) I believe that doing bugfix releases can show a commitment to quality better than not doing bugfix releases.

timely feature releases, high quality .0 releases, bugfix releases, they all contribute. My opinion is that timely feature releases are more important in growing an audience than high quality .0 releases, for the reason that people need to actually do significant work with .0 releases to run into bugs, and thus are not entirely new audience (unless .0 is seriously botched and doesn't actually work - that's a worst case scenario I discuss below). I believe that new people who run into bugs would not be pushed away from Zope 3 very much if it was clear to them bugfix releases happened regualrly.

Who or what would have been hurt exactly had Zope 3.3 been released
in june?
Well, we would have been hurt badly as the first beta release, the
one made at around that time was badly broken.

Who is we? Why would we have been hurt?

Because the first beta release wasn't even tested by the person who made it. Critical bits were missing. If we had released it as a final release, we would have looked like fools.

What about releasing it as a rc1? That's what release candidates are for. Even if we'd have made it .0 (which is not what I'm suggesting), we would've looked like fools only until we fixed it in a quick .1 release with a self-deprecating message.

Even if such a badly broken beta would've gone out (which I was not suggesting, obviously we do *some* testing), we could've done a bugfix release.

It would have been a major embarrassment. I don't know if you've noticed some recent threads, but Zope 3 has some serious credibility issues in the larger world.

The larger world being Chris Withers? :) Do threads on zope3-dev count as 'the larger world'? Perhaps I missed some thread.

We would have demonstrated pretty clearly that we don't care about

To whom?

To pretty much everyone who pays any attention to what we're doing.

That's not many people, so no biggie. Let's try to get more people to pay attention to what we're doing first. :)

What if we'd have followed up with bugfix releases?

And what makes you think we'd to that well. If we can get the first release so badly botched, what makes you think people will evenbother with later releases.

Again, going with the hypothetical worst-case scenario where we made a completely botched release:

* Because I bother with trying later releases if a current release of software doesn't work.

* Because the window in which we'd release the buggy release and fix the bug would be small, and people get the latest bugfix release when they download.

* Because linux distributions have packagers who put in the bugfix release instead of the botched release, so that many people don't even see the botched release.

* Because many people on windows try windows installers anyway, and the person making the windows installer would see the brokenness.

What about demonstrating we can release when we say we will?

Releasing crap on time is not acceptable to me.

So the state of the trunk in june was, in your evaluation, "crap" in june?

I don't think it's Zope 3's reputation that would've been hurt, as
 Zope 3.3 in june was not *that* buggy. Bugfix releases are also a
 completely accepted practice.
Except that we don't do much of those and we put little effort into
the ones we do do.

Let's do more bugfix releases. I don't think they can be avoided anyway.

Agreed.  Who's going to do it?  Who's going to fix the bugs?

Let's work on a plan so we're going to do this.

Given such a plan, and assuming clear instructions are available, I volunteer to make the Zope 3.3.1 bugfix release.



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to