Hey,
Jim Fulton wrote:
[snip]
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.
-1
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.
[snip]
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
quality.
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.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
