Re: Etch Release Tracking in debbugs (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Em Qua, 2005-03-16 às 15:03, Martin Michlmayr escreveu:
> * Daniel Ruoso <daniel@ruoso.com> [2005-03-16 14:38]:
> > > Also, we don't have any pseudo package for edge or release
> > > management stuff yet, so someone has to request it (and before
> > > requesting it think about how it will be used and what we really
> > > need).
> > That's what I'm trying to do here. But maybe I should start this
> > discussion in -release to be more productive.
> Sorry, I hope my reply didn't appear as unproductive or hostile.
> Since your last mail was sent directly to me with a CC to the list, I
> thought I'd just point out that it's not me making a decision here.
Hostile, no, I understood that you were saying it was off-topic for
-project.
> Anyway, I'd personally like to see more discussion about how to use
> this feature before actually going ahead and using it.
Sure, that's why I'm starting it even before the patch is applied on
debbugs and the pseudo-package is created, because, at this time, it's
just a proposal.
> 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.
Yes, that's how I see it.
> However, how far should this go? Should we have a bug report
> for *every* issue and have 'edge' depend on it?
I mean, every issue that afects the release as a whole, like the example
I made of init setting the locale variables at boot time. Like the
examples given by vorlon (gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6).
But I certainly don't see it depending on every RC bug in the BTS.
> 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).
Yes, because the huge amount of data. The tracking made for the release
would be only for major issues, issues that need qualitative information
more than quantitative, that's why I see debbugs as appropriate.
> 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.
This points to the other concern I have, how can we know if it needs
more features if we don't have almost any release tracking (I mean, more
than the reports from the release team, which are great)?
> 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.
The point I'm making is that we don't need much quantitative
information, but if the release team can make comments in the issues
inside debbugs, pointing dependencies, more people will know what are we
waiting to be ready, and then more people (who wants faster releases)
can help in the specific points holding the release. That's an important
step, i think.
> Maybe these thoughts will lead to some discussion.
I hope so, as I think this tracking (or any other tracking technique
choosen) should start *before* sarge release, to make it easier to keep
it on track later.
daniel
Reply to: