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

Re: testing-stable-unstable [was: Are there too many Debian developers]



On Mon, Dec 16, 2002 at 11:15:58PM -0700, Bdale Garbee wrote:
> It's pretty clear that making it possible for the BTS to record a range of
> versions for which a bug exists in a package is a good idea for a number of
> reasons.  I'd love to see a good general implementation.

I agree, I think I also filled a bug report against bugs.debian.org
about this some time ago. I think I had some interesting ideas,
but I can't remember what they are now.

It might be awkward keeping the versions up-to-date though,
especially when complications can exist, for instance debian-security.

You might find that the range of version becomes rather fragmented in
certain situations, eg. if a bug exists in stable and testing
versions, and a new upstram version is uploaded to debian-security.

For example:

Stable has XYZ version 1.0
Testing has XYZ version 2.0
Unstable has XYZ version 3.0

Version 4.0 is released that has a major security fix.


Versions =1.0 to <<4.0 are known to have bug n. (Note:
versions << 1.0 might also have bug n too).

Versions >=4.0 are known to be OK.


It is determined it is feasible to backport it
all the way to version 1.0, now:

Stable has XYZ version 1.0
Security has XYZ version 1.0.woody.1
Testing has XYZ version 2.0
Unstable has XYZ version 4.0

Now the range become fragmented, it is now:


Versions =1.0 to <<1.0.woody.1 are known to have bug n.
Versions =1.0.woody.1 to << 2.0 are known to be OK.
Versions =2.0 to <<4.0 are known to have bug n.
Versions >=4.0 are known to be OK.


Now consider, for reasons not related to this bug, at a latter
date, version 2.0 is patched and released in stable (eg. a point
release), now:

Versions =1.0 to <<1.0.woody.1 are known to have bug n.
Versions =1.0.woody.1 to << 2.0 are known to be OK.
Versions =2.0 to <<2.0.woody.1 are known to have bug n.
Versions =2.0.woody.1 to << 3.0 are known to be OK.
Versions =3.0 to <<4.0 are known to have bug n.
Versions >=4.0 are known to be OK.

Ideally any solution, would try to automate this as
much as possible.

Still, it might be difficult to automatically determine some of the
information required, for instance that version 1.0.woody.1 will fix all
versions up to but not including 2.0, I haven't given that any thought
though.

Any errors are strictly my own ;-).
--
Brian May <bam@debian.org>



Reply to: