Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, Mar 16, 2005 at 06:03:35PM +0000, Martin Michlmayr wrote:
> Anyway, I'd personally like to see more discussion about how to use
> this feature before actually going ahead and using it. There are the
> obvious use scenarios of actually using it to track real bug
> dependencies. I can also imagine an edge pseudo package to track some
> issues. However, how far should this go? Should we have a bug report
> for *every* issue and have 'edge' depend on it? Some projects do it
> like this and I think it works for them. On the other hand, we use
> the BTS for WNPP and I feel a specific system would be more suitable
> for it than the BTS (for example, using the BTS for WNPP makes it
> really hard to figure out when the status of a WNPP bug last changed).
For what it's worth, I feel like release issues are broad-based
and heirarchical. Something necessary for release like "finish
d-i" has multiple subtasks, and even subteams within the d-i
team to manage the process. The BTS currently does not have this
concept, and while joeyh's patch addresses the bug dependency
issue (thanks again Joey!) it doesn't address everything to
properly represent the questions.
> While I'm a great fan of proper tracking (including archival), I just
> wonder if the BTS is suitable, or maybe it just needs more features.
> For example, to keep track of tasks, it would also be helpful to have
> some kind of overview of the completion of a task (70% done). The BTS
> doesn't have this feature at the moment, maybe it should... or maybe
> we need some specific task tracking system. I personally haven't
> thought about it enough.
Indeed. The problem with this is that adding a lot of features
to the BTS while it's in use for etch may not be the wisest
move. The last thing we need is having our bug system go down
because we're hacking on it. I can imagine a parallel BTS
which is in development and can be used for this task. As it
proves its worth for tracking the release, code can be moved
in to mainline.
An alternate possibility is a whole new codebase that's
completely independant of the BTS, but can interface with
it. Things like the qa developer pages take this tactic. That's
what my project intends to be, and I've been able to bootstrap
it fairly quickly. It's already got the heirarchy built in,
and can track teams and tasks independantly of the BTS. I
still need to figure out the best way to interface it with
the BTS. The obvious problem with this approach is the "second
system disease" that joeyh talked about. The benefits are that
much of the logic is moved in to rails, making it incredibly
simple to add things like heirarchy and a relational DB
backend. I don't know which approach is better, and for now
I'm going to keep hacking on my codebase and see how it goes.
> Maybe these thoughts will lead to some discussion.
I'm happy to see it.
- David Nusinow
Reply to: