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

Re: Backports, Stable releases, Testing, Oh my!



    Hi.

* micah <micah@debian.org> [2014-02-26 16:48:45 CET]:
> Gerfried Fuchs <rhonda@deb.at> writes:
> >  Remove from stable-bpo if it's not expected to come back in is what we
> > actually do, yes.  And to have an overview of these situations I created
> > myself the diffstats page:
> > http://backports.debian.org/wheezy-backports/overview/
> >
> >  Looking at the "not available" page, I noticed that I need to remove
> > the twisted-* packages.  *heading over to franck*
> 
> The only reason that this one shows up to be removed is because the
> package names changed in unstable/testing from twisted-* to
> python-twisted-* so I don't think that this should be removed.

 The source packages were changed indeed after looking, but the removal
happened over a month ago.

> You might argue that a newer version from testing should be put into
> bpo and these removed, which I wont argue against, but updating the
> version in bpo From a new testing version should not be rushed due to
> this aggressive removal situation.

 I am uncertain what you call an "aggressive removal situation" here.
It happened a month ago in testing/unstable, and it was a RoQA.  Your
"aggressive removal situation" call is as unjustified as the "Oh my" in
the subject.  It would be nice if we can keep the tone civilized.

 The package doesn't exist in testing or unstable anymore since a month,
and given that we expect from backport maintainers to track the packages
they package, I would expect either an update on the situation; silence
doesn't improve the situation.

> Personally, I've found the aggressive removal from testing to be a shock
> in a number of cases.

 Then please discuss that issue with the ftp masters or release team.
As backports team we only want packages in backports which are expected
to be in the next stable release.  A package that isn't anymore in
testing/unstable for sure won't be part of the next stable release.

> I understand the motivations behind it, but it feels like a bit too
> aggressive pressure for my tastes. I've seen a lot of developers of
> packages who have found out their package will be removed from
> testing, but don't have the time to resolve the situation before it
> gets removed, resulting in much pulling of hair.

 I think you might be mixing two things up.  You are speaking about
removal from testing, but mean keeping them in unstable?  This isn't the
case here, the package was removed completely, not only from testing.

> I feel like the window for removal from testing is too short and is
> having negative consequences on the stress level of people whose
> volunteer labor contributions to Debian are already stretched thin.

 How long would be not too short for you?  A month seems to be too short
it seems.  Sorry 'bout that.

> Most everyone I've spoken to in this situation has said that it
> wouldn't be so bad if they had just a couple more days.

 A day or more doesn't make much difference after a month, does it?
Thing is, where would you draw the line then.  A month and a week?  Then
the next person would say a few more days won't hurt, and the time gets
extended endlessly.  That doesn't us get anywhere.

> I'd like it if that shock wasn't also quickly passed on to backports
> and instead things were examined a little more closely before purging
> packages. 

 Please.  "Quickly", a month?

> For example, say package X has been backported at version 1.0, version
> 2.0 is uploaded to sid, transitions to jessie and then has an RC bug
> that threatens removal. The problem with the 2.0 package has to do with
> some security issue upstream, which looks like it will be a deep code
> massage to fix and will take a while, too long for the testing removal
> auto firing squad. The maintainer wishes that they had not uploaded 2.0
> yet, because 1.0 was fine.

 This is a *completely* different situation and has nothing to do with
the twisted-* packages.  They weren't pulled from testing, they aren't
in *unstable* anymore neither.  Those packages don't exist anymore.
Yes, renaming is an unforunate situation, but even then, a month waiting
time doesn't seem to be too unreasonable, does it?

> Now backports sees the difference, because the 1.0 version has been
> removed from testing, so bpo now has a newer version than what is in
> testing. But the package is actually a *better*, but backports gets its
> package removed anyways.

 backports gets packages removed which aren't available anymore.  This
hasn't changed at all, it's nothing new, it happened in the past.

> Maintainer decides to eat the epoch and re-uploads version 1.0 to get a
> functioning package, uploads urgency high and package transitions to
> testing and a backport of the same package needs to be done again in a
> very short period of time after it was removed. 

 If the package still lives in unstable, the removal isn't done in
backports but rather discussed on how to proceed.  Like I pinged zigo
today about whether he could help get the RC fixed for
cloud-initramfs-tools so that testing has the package again.  That
package still is in unstable.

 So, stop the panic, please argument reasonable, and sorry for the
inconvenience that this removal-after-a-month caused.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |


Reply to: