[Zope3-dev] Zope X3.1 release

[Stephan Richter]

On Thursday 03 March 2005 04:45, Martijn Faassen wrote:
> > That's exactely the point. XXX comments should not be deferrable. If they
> > are, then they need to be TODO comments. So often (as in 70-80% of the
> > time) it turns out that a XXX is a TODO. Somebody just has to go through
> > them.
>
> Deferring an issue or not is the responsibility of the release manager,
> and the release manager should ideally have access to everything that
> needs to be done within some issue tracker overview.

But this is not an ideal world.

> It should not be 
> the responsibility of the developer writing the original code to declare
> an issue non-deferrable. The developer shouldn't even have that power in
> the first place.

Well, I think he should have that right. For example, if I am working on a 
hard and complex task and I discover an untested code segment (maybe because 
it has a bug), then I usually just drop an XXX comment there. If I would 
create a bug issue first, then I would need to explain how to cause the 
issue, describe it, etc, etc. This is too big of a diversion in such a case.

If I would be required to post an issue in the tracker in this case, I would 
do nothing, which would result in no report at all.

> It is surprising to me that, with a project with as much quality
> assurance during development as Zope 3, there are 80 non-deferrable
> have-to-fix issues before a release can be done.

Well, that's how it is; better have them than not.

> But, it actually turns out that it is only 20-30% of those, so only
> about 20 cases. The rest can safely be deferred anyway. This shows that
>   the policy of XXX being non-deferrable is simply not working.

No, this means that the developers are not aware of the semantics of XXX 
versus TODO comments.

> With the current policy in place, the release manager has to go through
> the issues in the issue tracker *and* through the XXX points, there
> being no single overview of the release status.

Yep, this is the reason the release manager's job is a really difficult one. 
Noone ever said it is easy. Doing the actual release packages and writing the 
announcements and release notes is actually the fun part, sort of the reward. 
The hard work is to organize the bugs, issues and get people to work on them 
(and realizing that you as the release manager will have to fix a lot of them 
yourself). If you are not willing to do that work, then don't sign up for the 
job.

BTW, I have done already a good chunk of that work now by looking and 
organizing the bugs, create a to-do list for the release and fixing about 50% 
of them. In fact, I have been working on the release sicne early December; 
the CA cleanup and apidoc tool revision were necessary steps and part of the 
to-do list

> Without issue tracker, 
> it's hard for other people to get an idea, it's hard to assign issues,
> it's hard to communicate about issues. In addition, the release manager
> will have to do two different things to actually defer an issue, one of
> which has an obscure record (SVN archives).

Well, XXX comments are trivial and usually anyone can fix them by reading 
them. If not, it is most likely a TODO anyways.

I have tried once to make the release manager's life easier by creating a Zope 
3 bug tracker that had a lot of cool features for a release manager and I 
even had started working on an automated issue generation for XXX comments. 
But there was no interest in keeping the tracker alive and help maintaining 
it, so it went away when I was not around for a couple of months. I hate to 
bring it up again, but it is a manpower issue.

> A better policy would be for the release manager to completely ignore
> all XXX comments, and thus force people to create issues for matters
> that they consider really important, as they should've done in the first
> place.

That's not an option (at least for me). Well, in this case you might as well 
delete all the XXX comments now, because people putting in XXX comments would 
not create an issue in a lot of the situations. (I certainly would not and I 
know there would be no consequences because noone knew I saw the bug/issue.)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training