[Zope3-dev] Roadmap for Zope 3.4

[Martijn Faassen]

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