[Zope3-dev] Re: Issue Collector

[Ken Manheimer]

Stephan, my apologies for taking so long to respond to your
suggestions - i put it aside to answer when i had a moment, and then
forgot about it.

For that matter, thanks for reminding me about it - i like the ideas,
and like the idea of improving the collector, in general.  As you can
probably tell from the basicness of the thing, i don't have time or
mandate to spend time on it, except for small tweaks - can't even get
to some old tracker features i'd like to have in the collector, like
issue subscriptions and 'divert' (where a duplicate issue can be
combined with its corresponding one, including the requester and any
issue subscribers in the correspondence for the remaining issue).

On Sat, 30 Mar 2002, Stephan Richter wrote:

> now that I started working with the Collector, I found a couple of features 
> that would be cool:
> 
> 1. You should be able to specify issue dependencies. Really, a simple 
> system saying, this issue depends on issues X, Y and Z will be totally 
> sufficient.

Certainly would be useful, it suggests a couple of things to be done:

 - Provide UI to refer to other issues, and their relationships.

 - Change the UI to indicate issue dependents from within an issue.

Seems like you'd want to be able to detect from an issue its
dependents and dependencies - suggests storing the structural info in
the collector, itself, and not the issues.

 - Optional - provide some UI to present the collector contents in
   terms of dependencies...

> 2. I often find myself writing the same message twice; once for the CVS and 
> then as comment in the issue. It would be incredible cool, if I could put a 
> marker in my CVS message that automatically creates a followup to an issue. 
> Here some examples for some markers:
> 
> Issue 48: Resolve
> Issue New: Comment
> Issue 50: Accept srichter
> 
> I know that might be tough to implement, but would be so helpful, since it 
> also keep the collector better up-to-date. The syntax should be very simple 
> and short as well.

This verges on probably the most dear feature, and also probably the
one with the most different ways it can be sliced - email input to the
collector.

Perhaps we could handle it less general way by hooking the CVS checkin
handling mechanism (the email notifications, etc) to detect the
checkin markup and route the changes according to some table entries
(the CVS notifications stuff is already table driven) and dispatch the
updates via xml-rpc.

> What do you think. Is that possible?

Certainly possible.  Also desirable.  Will i have any time at all to
even chip away at it?  Not any time soon, unless management can be
convinced it's very high priority (i'm not convinced of that, myself).

I would be glad to shepherd efforts to do this, time permitting,
though - all the code is publically accessible:

  The collector is accessible from the CMF public cvs, as
  CMFCollector.

  The CVS stuff can be checked out from the CVSROOT of the public
  repository - the key items are traffic_table.py and
  postcommit_actions (both python scripts).

Again, sorry about the delay responding - i did have to think about
it, and then it fell off my radar...

-- 
Ken
klm@zope.com