Re: Update on "upload of GNOME 2.6 to unstable" status
On Thu, May 20, 2004 at 12:09:54PM +0100, Colin Watson wrote:
> On Thu, May 20, 2004 at 01:04:37PM +0200, Sven Luther wrote:
> > On Thu, May 20, 2004 at 11:48:01AM +0100, Colin Watson wrote:
> > > That's actually exactly the current state. However, it's more difficult
> > > to get user testing of t-p-u uploads before they get into testing, so
> > > it's not really something we want to rely on too much.
> >
> > Ah, last we tried this in february or so, testing-proposed-update was
> > not being autobuilt, and the result was that it was not usable for
> > debian-installer, but then maybe it has changed since then ?
>
> t-p-u has been autobuilt for years. I certainly have a package which was
> uploaded to t-p-u last September and autobuilt.
Well, it certainly did not when we tried to use it for debian-installer
shortly after beta2 out, if i remember well, which is way we are not
using it for d-i purpose. But then it may have been another problem, not
sure.
> > If so, then this is the ideal method for solving the current problem,
> > and we could quite well upload gnome 2.6 to experimental and use t-p-u
> > for RC bug fixes in testing should they show up,
>
> Since the autobuilders build against unstable, uploading GNOME 2.6 to
> unstable affects lots of things; it's big enough that, at this stage, it
> pretty much totally commits us to having GNOME 2.6 in sarge, even with
> t-p-u. As such, it is very much the release team's responsibility to
> ensure that the risk is as close to zero as can feasibly be managed.
Yep, i understand that. That said, given the timeframe involved, not
moving 2.6 to unstable, pretty much commits us to _not_ having GNOME 2.6
in sarge one it is released, so, it is indeed a choice to make.
> Please, it will be a lot less work to demonstrate that GNOME 2.6 is
> ready than to try to find hacky workarounds.
As far as i can tell, t-p-u has never worked as it should, and using a
single repository experimental which is not autobuilt is no user
friendly way of getting testing done. It is a real pain to use
experimental in the current state of things, so we will get little
testing done, especially on the non mainstream architectures.
Friendly,
Sven Luther
Reply to: