Re: The png fiasco, libqt2, and GNOME
On Sun, Jan 06, 2002 at 10:46:52PM +1100, Daniel Stone wrote:
> ----- Original Message -----
> From: "Steve M. Robbins" <steven.robbins@videotron.ca>
> > The reason I'm writing here is that I would like to see the problem
> > packages (libqt2 and related kde apps) stay out of TESTING until
> > this issue is resolved.
> >
> > I gather that the way forward chosen for QT2/KDE is to recompile
> > everything against libpng3. Chris Cheney and Daniel Stone:
> > please confirm or correct this!
>
> Yes. Since we're already halfway there, going back would only cause more
> confusion.
> > However, if the rebuilt libqt2 gets into testing before the rebuilt
> > KDE apps, then the latter will suddenly break for everyone using the
> > "testing" distribution. It seems prudent to hold up the migration to
> > testing until all the packages are ready to go.
>
> This is not something that can be done with bugs,
I don't understand why you say that.
The TESTING FAQ (http://people.debian.org/~jules/testingfaq.html)
describes the rules for moving from UNSTABLE->TESTING:
3.What determines when a package moves into testing?
A (particular version of a) package will move into testing when it
satisfies all of the following criteria:
1.It must have been in unstable for 10, 5 or 2 days, depending
on the urgency of the upload;
2.It must be compiled on (at least) every architecture which the
corresponding version in testing was compiled on;
3.It must have fewer release-critical bugs than, or the same
number as, the version currently in testing;
4.All of its dependencies must either be satisfiable by packages
already in testing, or be satisfiable by the group of packages
which are going to be installed at the same time;
5.The operation of installing the package into testing must not
break any packages currently in testing. (See below for more
information)
Rule #3 implies that opening RC bugs on the package will keep it
out. I can't find any trace of an RC bug being open for version -17
(the version in testing), so I presume that opening one single RC
bug for -18 will keep it out of testing.
> it's something that needs to manually be done by AJ.
I suppose that AJ could do it manually. But I don't see why we ought
to load him with even more busy work. Using the BTS appears to me to
be the easier option. Moreover, it keeps the control with you, the
maintainer, where it ought to be.
> > Therefore, I'd like to reopen Bug #126808 on libqt2 and set its
> > severity to "critical". I believe that would keep the new libqt2
> > (and everything that depends on it) out of testing. When all the
> > packages are ready, we would wait ten days (so that all the packages
> > become candidates for "testing"), then close the bug.
>
> Bug AJ to do it. It is not a bug in libqt2, and it is most certainly not
> critical.
I would suggest that the consensus opinion of the last week is that
the partial upgrade breakage for the libqt & KDE packages was a problem.
I am only concerned about avoiding the same problem occurring when
the packages trickle into TESTING, one by one.
If we let the updated libqt2 into TESTING without simultaneously
updating *all* the packages that use it and libpng, then TESTING
becomes unreleasable. That is a problem, no?
I don't care how this problem is avoided. I am only concerned that
if nothing is done within a day or two, then libqt2 *will* go into
testing. To my mind, putting an RC bug on libqt2 is the easiest option.
If you feel otherwise, I'll leave you to fight it out with AJT.
Regards,
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: