cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Date Thu, 09 Oct 2003 10:38:05 GMT
Bertrand Delacretaz wrote:
> Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
> > ...And we also create a process in the following way:
> > - the wiki feature request page is scanned from time to time (the mails
> >   help there)
> > - A new entry is evaluated (perhaps the feature doesn't make sense or
> >  is a bug or is a really cool thing etc.) and if accepted added
> >   to our planning document.
> > So the planning document in our docs contains the approved list of
> > feature
> > requests....
> See what you mean, but this could also be a list of pointers to
> bugzilla.
Ok. Perhaps automatically generated somehow?

> IMHO if we start to use bugzilla more seriously, we will need a
> slightly more precise categorization of issues:
> -actual bugs with different severity levels (can do)
> -patches ([PATCH] header is a hack but more or less workable)
> -feature requests
> -release-related stuff (if we want to use bugzilla dependencies to
> prepare releases)
> -more?
> Meaning that we shouldn't count just "open issues" anymore, rather
> "open bugs", "open feature requests", "open patches" etc.
Yes, that's true!

> On Monday we were focused on "total open issues" which is wrong IMHO.
Right, bugs are more important imho.

> I think this is easier to do in bugzilla where everything is dynamic.

> This might need adding more possible values to the "severity" field,
> dunno off the top of my head how easy it is to do. Otherwise we can use
> title headers like [RELEASE] [REQUEST] etc.
> For feature requests, my suggestion would be to do so:
> -Let them come in bugzilla
> -Evaluate them often, and close the ones which seem too far away with
> resolution=LATER
> -Explain all this on a wiki page, with links to bugzilla queries to
> show what's current
Ok, we can give it a try.

> This would help give more importance to bugzilla for planning/progress
> monitoring stuff, which I think is good.
> And in this way we avoid the need to synchronize lists or move stuff
> between bugzilla and the wiki.
Yes, that's right.

Ok, I tend to agree with you that using bugzilla is better (and easier).
But the differentiation using [PATCH], [XYZ] is a little bit ugly. If
it's possible to use a different (better) approach there I'm fine with


View raw message