[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DPLs : what do you think about ...

On Mon, Dec 14, 1998 at 03:18:00AM +0100, Wichert Akkerman wrote:
> > Wichert:  I know you have automated this, is it possible for you to have
> > things track bugs in both frozen and unstable or would this require
> > extensive modification of the BTS to accomidate you?
> No, the BTS does not support this. To be able to really track bugs 
> you have to know more about it:
>  - for which architectures the bug shows itself (most bugs will be for
>    all architectures). We could probably also use a source-architecture
>    to indicate a problem in the source (like not removing debian/files).
>  - which versions of the package have the bug (versionranges such as
>    dpkg uses might be appropriate).

Hmm, these sound like they might prove interesting for the BTS to know
the architectures of the bug, but I'm not sure if ranges can easily be
done, mostly because they'd need to be able to be changed.  This is
probably not going to be a simple BTS mod.

> I already check if the package is in the frozen distribution for one of
> the architectures being released. For the interested, the code to scan
> the BTS spool is available in ~wakkerma/bugscan-4 on master.
> I think it is quite easy to add pseudoheaders to the BTS. We would
> also need to extend the version pseudoheader and add a command to
> change it later. 
> Also we will have to make sure that people actually supply this information,
> and we will probably need a group of people to check this.

I'm not so sure the latter is going to be easy.  Sounds more long term
unless someone feels like playing with the BTS code.

> > This may or may not be possible to track bugs in unstable AND bugs in
> > frozen anytime soon.  If it can be done, I think it'd be a good thing. 
> > It's kinda up to Wichert though.
> It's not up to me, it's up to people implementing this for the BTS. Once
> that is done it will probably be almost trivial to add it to my bugscan
> scripts.

I'm glad your end of it will be so easy to implement.  =>

> > Monitoring the critical bugs throughout the development cycle
> Starting with slink I have fully automated the scripts that scan the BTS
> data, so it is very easy to do this now (to the limited extend that
> a release-critical bugreport helps). And as a bonus you get a nice graph
> that shows how we are doing :)

<oohs and ahhs>

"Shall we play a game?"  -- WOPR

Reply to: