Re: Uploads to experimental instead of unstable (was RFS: vbetool (QA upload))
Well, I didn't thought this request will turn into this type of
discussion.
Anyway, just to add my point of view : I mostly agree with Neil
position, as most of uploads should go to experimental during the
freeze.
But, for this particular upload (and maybe some others), targeting
unstable is IMO the better solution because :
- The changes are very limited.
- Even if it's not fixing RC bugs, it increase (a few) the quality of
the package. So why exclude Lenny about this ? Remaining RC bugs are
just to hard to be fixed by contributors like me.
The only risk I can imagine is breaking stuff with the rebuild of the
package.
It was intentional for me to target unstable for those reasons. Now, if
it's really a problem, I'll targeting experimental and make more
"unstable changes" (like taking the new upstream tarball).
Regards,
Julien Lavergne
On Thu, 2008-12-11 at 10:08 +0000, Neil Williams wrote:
> On Thu, 11 Dec 2008 13:26:55 +0900
> Charles Plessy <plessy@debian.org> wrote:
>
> > Le Wed, Dec 10, 2008 at 07:26:34PM -0600, Boyd Stephen Smith Jr. a
> > écrit :
> > > On Wednesday 2008 December 10 17:07:06 Julien Lavergne wrote:
> > > >- Since unstable is "frozen" for Lenny, I want to let the
> > > >possibility to upload fixes in unstable for migration into lenny.
> > >
> > > That's not quite how I understand it. Right now testing is frozen,
> > > which means packages won't auto-migrate from unstable to testing
> > > unless someone pings the release team. Still, I'm new so I could
> > > be mistaken.
>
> Unstable is also "closed" so that other packages can migrate more
> easily. Uploads not related to Lenny should go into experimental. New
> upstream versions have a lower likelihood of being deemed acceptable
> for migration by the release team. However, you also need to fix
> something in the upload that is relevant to the release in order for
> the release team to allow the migration. A "ping" is a waste of time -
> a fix for an RC bug is what is needed. If there is no RC bug to fix
> with this upload then upload to experimental, not unstable (or don't
> upload until after Lenny is released).
>
> > Hi,
> >
> > If a fix has to be uploaded to Lenny, it can be done two ways:
> >
> > - Direct upload to testing-proposed-updates.
> > - Upload to unstable and manual migration ("unblock" by release
> > team).
> >
> > If the package goes through unstable, it will benefit from the
> > testing phase before migration. For this reason, updates that are not
> > suitable for Testing can be uploaded to Experimental instead of
> > Unstable during the freeze, so that both ways of Lenny update are
> > open.
>
> It's a bit more complicated than that - 'testing-proposed-updates' is
> for times when unstable already has a newer version of the package that
> will not migrate and an RC bug is found in the older version in
> testing. The preferred method to fix RC bugs is to be able to upload to
> unstable and migrate with permission from the release team. Uploading
> other cruft to unstable gets in the way of that process.
>
> Unstable has had to be all-but-closed as a technical step to solve a
> social problem. Uploads should not be targeted at unstable simply
> because uploading stuff into unstable that is not intended for Lenny
> complicates the transition of packages that *are* intended for Lenny.
> New bugs can arise from interactions between the new packages and the
> ones intending to migrate, which delay the migration of the package
> intended for Lenny. It's particularly relevant for libraries but also
> for packages that use or provide daemons etc.
>
> If a package on mentors is *not* meant to be part of Lenny, if your
> upload does not fix an RC bug in Lenny, then consider unstable
> off-limits and make your upload into experimental - or don't upload at
> all and work on an RC bug instead.
>
> The more differences there are between unstable and testing at this
> time, the harder it can be to actually fix the bugs which then means
> that the entire freeze goes on for longer. Ignoring this problem
> doesn't make it go away - uploading random junk to unstable actually
> prolongs the problem for everyone else. Stop it, please.
>
> If the upload is not for Lenny, use experimental or simply don't
> upload - spend your time fixing a bug in Lenny instead. It may only be a
> small effect but there seem to be precious few people trying to help
> get Lenny released and everything should be done to support the effort
> to get the release done so that we all get back to uploads into
> unstable. I have some 30 uploads that need to be made right now but
> only 2 are actually going to be uploaded and both to experimental. Once
> Lenny is released, then the inevitable problem is that unstable gets
> *so* broken immediately after a release that it can become impossible
> to actually build certain stuff for unstable for a few weeks.
> Experimental is the best place for all uploads until both Lenny is
> released and unstable has calmed down from the immediate aftermath of
> the release.
>
> Not having your package in unstable is a pain and an inconvenience? So?
> The quicker Lenny is released, the quicker everything gets back to
> normal, so use experimental!
>
Reply to: