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

Re: May I upload dfsbuild to testing-proposed-updates?



John,

On Wed, Jan 10, 2007 at 09:13:01AM -0600, John Goerzen wrote:
> On Wed, Jan 10, 2007 at 11:51:09AM +0100, Marc 'HE' Brockschmidt wrote:
> > John Goerzen <jgoerzen@complete.org> writes:
> > > I have prepared an update to dfsbuild that fixes 2 RC bugs: #404563 and
> > > #404555.

> > If your final patches look like the two patches in the BTS for these
> > bugs, that should be fine. Please mail us again after you've uploaded
> > the package.

> Thanks, Marc. They are exactly those.  The package is uploaded:

> From: Debian Installer <installer@ftp-master.debian.org>
> To: John Goerzen <jgoerzen@complete.org>
> Subject: dfsbuild_0.99.3_i386.changes is NEW
> Date: Wed, 10 Jan 2007 14:32:02 +0000

> (new) dfsbuild_0.99.3.dsc optional utils
> (new) dfsbuild_0.99.3.tar.gz optional utils
> (new) dfsbuild_0.99.3_i386.deb optional utils

I'm sorry that you've gone to the trouble of uploading this, because it
isn't going to work.  Aside from being caught in NEW (because dfsbuild was
removed from testing previously), if it's ever approved out of NEW it will
be rejected anyway for having a version number newer than that in unstable.

It also doesn't seem to fit with the policy for t-p-u, which is that uploads
should include a minimal diff against testing because there's approximately
zero user testing before such packages are approved so eyeballs are the only
defense against regressions.  Well, since dfsbuild has been removed from
testing, a minimal diff isn't really possible; maybe this .3 build is a
minimal diff against .2, but the release team can't really judge that anyway
until the package is out of NEW...

Anyway, could you explain what the haskell changes are that prevent having a
single dfsbuild package that's buildable in both etch and sid?  Getting out
of the current situation is going to require a new upload to unstable one
way or another AFAICS; ideally that would be one we can hint into testing
the normal way and disregard the version in NEW.  If that's really not
possible, the next best would be to upload a .4 to unstable that fixes the
RC bugs for that branch, and then accept .3 from NEW.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: