Re: More 5 november in the release schedule [and 1 more messages]

[Marc Haber]

On Sun, 13 Nov 2016 15:43:26 +0100, gregor herrmann
 wrote:
>On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote:
>
>> On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
>>  wrote:
>> >Finally, there's a thing called "trust": I trust the Release Team does
>> >this solely in order to keep the freeze time as short as possible,
>> >everybody hates that time anyway. This trust was created by the very
>> >people behind it, and the way they acted in the past months.
>> This is exactly the problem I have with the current policy: I fail to
>> see why this measure will shorten the freeze.
>
>It already has shortened the freeze for jessie which had more or less
>the same policy in place:
>
>https://wiki.debian.org/DebianReleases#Release_statistics

By 13 days. I don't think that's worth it.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Lars Wirzenius]

On Sun, Nov 13, 2016 at 11:23:24AM +, Steve McIntyre wrote:
> FTAOD: I thank the release team for their tireless work on making each
> Debian release better than the last. We keep on adding more and more
> software and making things harder and harder to stabilise and release,
> and I 100% support their efforts to improve the process of releasing
> Debian.
> 
> I hope that the vast majority of Debian contributors think the same.

+1. I agree with Steve.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: More 5 november in the release schedule [and 1 more messages]

[gregor herrmann]

On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote:

> On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
>  wrote:
> >Finally, there's a thing called "trust": I trust the Release Team does
> >this solely in order to keep the freeze time as short as possible,
> >everybody hates that time anyway. This trust was created by the very
> >people behind it, and the way they acted in the past months.
> This is exactly the problem I have with the current policy: I fail to
> see why this measure will shorten the freeze.

It already has shortened the freeze for jessie which had more or less
the same policy in place:

https://wiki.debian.org/DebianReleases#Release_statistics


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles: Happiness Is A Warm Gun


signature.asc
Description: Digital Signature

Re: More 5 november in the release schedule

[Ole Streicher]

Marc Haber  writes:
> I would feel a lot less uncomfortable if the teams who are using
> automated tools to auto-file RC bugs for third-rate policy violations
> which will auto-remove a (99,99% of the cases) perfectly working
> package from testing in a time where a maintainer would probably not
> dare to touch his maintainer scripts for fear of creating a really RC
> bug which will in turn get the package auto-removed from testing would
> refrain from doing their auto-foo during the freeze.

I would rather prefer to get the results of these tools *before* the
freeze. 

In the Jessie release process I had the impression that many tests were
done only after the freeze, putting some unneeded pressure to the
maintainers. It would rather be nice to run them *now*, or even a few
months earlier.

> I do appreciate automated tests, and while I think it can be discussed
> whether the policy violations found by those automatic tests need to
> be RC, I firmly believe that these tools should not be used as a
> weapon against packages.

They should rather be part of the CI process, also allowing to discuss
them during the normal evolution, not in the pressing time of a release.

But this is based on my subjective, unproven feeling.

>>The goal of autoremovals is to provide an incentive for people
>>to deal with problems in their packages _early_.
>
> Managerspeak. Even at work I hate people who talk about giving
> "incentives" while they actually threaten.

The problem I see here is: why doesn't the RC bug appear _early_, but
maybe only during freeze?

>>And as I said previously: if a maintainer of a dependency of yours
>>doesn't care: NMUs for RC bugs have a far lower threshold - even
>>0-day NMUs are possible if the maintainer is really completely
>>asleep. (DevRef 5.11.1)
>
> So this is a method to force people to take additional
> responsibilities for dependencies as well in addition to the
> responsibilities they have taken voluntarily? Well, _this_ will
> clearly motivate people.

I must say that I see no other way: if a dependency of your package has
n RC bug, nobody fixes it and you want your package to be kept in, you
have to deal with it yourself.

I would only propose (and hope) that from the release team it is also
accepted to re-upload my own package rebuilt without the buggy
dependency -- very often dependencies are optional, and it may help to
cut the dependency on a broken, poorly maintained package.

For example, many of my packages have lots of dependencies just to run
extensive build time tests. Removing them would not make the package
worse. Or it may be better to have the package with reduced
functionality that to get the package removed completely.

Best regards

Ole

Re: More 5 november in the release schedule

[Samuel Thibault]

Samuel Thibault, on Sun 13 Nov 2016 12:25:33 +0100, wrote:
> Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote:
> > But we currently treat "does not build at all" or "eats my entire
> > ~ on installation" the same way like "leaves an idle directory in
> > /var/lib after an
> > install-purge-reinstall-old-version-update-remove-reinstall-purge
> > cycle".
> 
> And I guess "leaves an idle directory" is a very good candidate for
> stretch-ignore, as was done in the past.

By that, I mean:

- either it's easily fixable, and thus there is no reason the maintainer
can't fix it in time, and if he doesn't, one can be doubtful about the
quality of the rest of the package, for which no RC bug report has been
reported _yet_.

- or it's difficult to fix, and thus considering the little consequence,
the release team will probably accept a stretch-ignore.

Samuel

Re: More 5 november in the release schedule

[Holger Levsen]

On Sun, Nov 13, 2016 at 12:16:46PM +0100, Marc Haber wrote:
> Yes. But we currently treat "does not build at all" or "eats my entire
> ~ on installation" the same way like "leaves an idle directory in
> /var/lib after an
> install-purge-reinstall-old-version-update-remove-reinstall-purge
> cycle".
 
no, we don't.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[Tollef Fog Heen]

]] Marc Haber 

> On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst
>  wrote:
>
> >If the release team is willing to consider exceptions when
> >the automated machinery was jumping the gun a little, however, then
> >okay, I think it might be a good idea to try this out.
> 
> If you only get an exception if your package is so important that the
> press will mention us like "Debian stretch is missing the important
> foo package", then I wouldn't want to even try this. If getting an
> exception is the normal case, then, fine, try it. But why would be
> bother to write this in policy if we intend to do this as the normal
> case?

I don't understand why you think the criteria for allowing a package
back in is «is important».  It might just as well be «is the maintainer
doing an honest effort here, or is it just a drive-by upload?» or
something else.  I'm not going to pretend to be able to read the release
team's collective mind.

> >Being rigid about such policies is never a good thing, though.
> 
> Yes. And I am afraid that this policy is being as rigid as a two inch
> steel wall.

It sounds like you have had very different interactions with the release
team than I have.  In my experience, they're doing a difficult job, and
doing it well, trying to accomodate everybody while still making
progress towards releasing.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote:
> But we currently treat "does not build at all" or "eats my entire
> ~ on installation" the same way like "leaves an idle directory in
> /var/lib after an
> install-purge-reinstall-old-version-update-remove-reinstall-purge
> cycle".

Don't confuse the bar with the levels catched by the bar, which can be
very different indeed.

And I guess "leaves an idle directory" is a very good candidate for
stretch-ignore, as was done in the past.

Samuel

Re: More 5 november in the release schedule

[Steve McIntyre]

Marc Haber whined:
>On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier 
>
>>"""
>>The release managers may make exceptions to these guidelines as they see
>>fit. *Such exceptions are not precedents and you should not assume that
>>your package has a similar exception*. Please talk to us if you need
>>guidance.
>>"""
>>(Emphasis from original - 3rd paragraph from the top)
>
>This is a quite nice opportunity to say something like "you haven't
>been nice enough to us in the past or you have dared to speak up when
>you didn't like what we did, so you're free to take a hike with your
>package, have a nice day".

The release team are volunteers, working hard and trying to do the
best thing for Debian as a whole. Insinuations of unfairness and
personal attacks are hardly likely to motivate them to continue to
donate their free time, are they?

>I find that unnecessarily humiliating and will probably not do this
>and rather live without my package in stable for this release.

Or, you know, you could just ensure that your packages are working
well and this doesn't come up?

FTAOD: I thank the release team for their tireless work on making each
Debian release better than the last. We keep on adding more and more
software and making things harder and harder to stabilise and release,
and I 100% support their efforts to improve the process of releasing
Debian.

I hope that the vast majority of Debian contributors think the same.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 13 Nov 2016 12:11:06 +0100, Samuel Thibault
 wrote:
>Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote:
>> I'd rather have a badly maintained package than none.
>
>That's probably the real point where people differ.
>
>To me, releasing in Debian means some given level of quality.

Yes. But we currently treat "does not build at all" or "eats my entire
~ on installation" the same way like "leaves an idle directory in
/var/lib after an
install-purge-reinstall-old-version-update-remove-reinstall-purge
cycle".

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote:
> I'd rather have a badly maintained package than none.

That's probably the real point where people differ.

To me, releasing in Debian means some given level of quality.

Samuel

Re: More 5 november in the release schedule

[Holger Levsen]

On Sun, Nov 13, 2016 at 11:55:13AM +0100, Marc Haber wrote:
> This means that we didn't to this with squeeze, wheezy and jessie. 

we did this for jessie. the fact that you were not paying attention
doesnt change reality.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:56:09 +0100, wrote:
> On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault
>  wrote:
> >Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
> >> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre 
> >> wrote:
> >> >Releasing Debian is work for all of us, not just the Release Team...
> >> 
> >> So you are actually suggesting that people who are neither on the
> >> release team nor maintaining a key package are not working?
> >
> >He is very obviously not suggesting that. He is just saying what he
> >said: the Release Team shouldn't be doing all the work to get the thing
> >out.
> 
> And to relieve the release team they have decided to make re-entering
> testing a manual process. I only see one way that wouldn't falsify
> that assumption, and that way is bad.

The way I see to falsify is that the release team will only have to make
a *decision* about fixes done by the maintainer, instead of having to
fix themselves at the last minute some packages they don't even know
about. That's way less work.

Samuel

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:55:13 +0100, wrote:
> On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault
>  wrote:
> >Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
> >> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius  wrote:
> >> >I'm even willing to justify my opinion: Keeping testing in a state
> >> >that can be released seems to be the only way in which we can make a
> >> >release in a reasonable time frame. We've tried several other
> >> >approaches, which haven't worked. The approach of "let's freeze and
> >> >then try to fix things" didn't work. Let's not try it again.
> >> 
> >> I do not think that it is a service to our users to release an
> >> incomplete distribution just for the sake of keeping a date.
> >
> >As said above, it's *not* a matter of "keeping a date", but "getting
> >something out at all within reasonable time".
> 
> This means that we didn't to this with squeeze, wheezy and jessie.

That was an awful lot of work for the release team, as well as decisions
to abitrary drop some packages, to get something out, which they
shouldn't have to bear.

> I have seen installations moving away from Debian because we keep
> releasing too often.

You'll always deceive somebody when doing anything in any kind of way.

Samuel

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 13 Nov 2016 10:46:07 +, "Adam D. Barratt"
 wrote:
>On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote:
>> This is a quite nice opportunity to say something like "you haven't
>> been nice enough to us in the past or you have dared to speak up when
>> you didn't like what we did, so you're free to take a hike with your
>> package, have a nice day".
>
>Only if you start from an assumption of bad faith.

Or from an assumption of being human. I have seen this way of people
behaving too often in the past (including in myself). Feel free to
prove me wrong. I would really appreciate that.

>> I find that unnecessarily humiliating and will probably not do this
>> and rather live without my package in stable for this release.
>
>I find your characterisation of a team and process I've invested several
>years in trying to make the best that we can demotivating, frankly.

I apologize for speaking my mind.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault
 wrote:
>Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
>> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre 
>> wrote:
>> >Releasing Debian is work for all of us, not just the Release Team...
>> 
>> So you are actually suggesting that people who are neither on the
>> release team nor maintaining a key package are not working?
>
>He is very obviously not suggesting that. He is just saying what he
>said: the Release Team shouldn't be doing all the work to get the thing
>out.

And to relieve the release team they have decided to make re-entering
testing a manual process. I only see one way that wouldn't falsify
that assumption, and that way is bad.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault
 wrote:
>Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
>> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius  wrote:
>> >I'm even willing to justify my opinion: Keeping testing in a state
>> >that can be released seems to be the only way in which we can make a
>> >release in a reasonable time frame. We've tried several other
>> >approaches, which haven't worked. The approach of "let's freeze and
>> >then try to fix things" didn't work. Let's not try it again.
>> 
>> I do not think that it is a service to our users to release an
>> incomplete distribution just for the sake of keeping a date.
>
>As said above, it's *not* a matter of "keeping a date", but "getting
>something out at all within reasonable time".

This means that we didn't to this with squeeze, wheezy and jessie. In
fact, we were in a so reasonable time frame for those three releases
that I have seen installations moving away from Debian because we keep
releasing too often.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Niels Thykier]

Marc Haber:
> On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann 
> wrote:
>> I don't quite understand where all this fuzz about auto-removals
>> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
>> and they were also in place for the jessie freeze [1], with the small
>> difference that now the point-of-no-return is a month before the hard
>> freeze, and in jessie it started with the hard freeze.
> 
> If the jessie release actually had a point-of-no-return, then it was
> this seldomly and/or silently enforced that I totally missed it.
> 
> I don't have anything against autoremovals, I am strongly opposed
> against the "once you're out, you'll stay out" since I fail to see the
> advantages of this approach aside from "giving incentives".
> 
> For me, this "incentive" will most likely have the opposite result.
> 
> Greetings
> Marc, who is about to stop caring just a bit more
> 

It was listed in at least two d-d-a mails:
 * https://lists.debian.org/debian-devel-announce/2015/02/msg0.html
 * https://lists.debian.org/debian-devel-announce/2014/09/msg2.html

Plus the jessie freeze policy;
 * https://release.debian.org/jessie/freeze_policy.html

  If you feel we could be more vocal with our announcements, please do
  not hesitate to let us know.


These days we /also/ have a [release calendar] now that you can import,
so you can see the deadlines in your favourite calendar.  I admit, we
did not have that for Jessie - but hopefully it will help people for
stretch.


Thanks,
~Niels

[release calendar] http://release.debian.org/release-calendar.ics

Re: More 5 november in the release schedule [and 1 more messages]

[Marc Haber]

On Sun, 13 Nov 2016 11:07:18 +0100, Christoph Biedl
 wrote:
>Marc Haber wrote...
>
>> This is exactly the problem I have with the current policy: I fail to
>> see why this measure will shorten the freeze.
>
>I don't. But I'd say we'll just watch what's going to happen and resume
>this discussion once stretch is released.

Agreed. Maybe I will be proven wrong the same way as I was proven
wrong when I claimed that jessie is going to be our most painful
release since the glibc migration.

I surely hope that I'm wrong.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst
 wrote:
>What if I did notice, but fixing the bug takes longer than the 15 days
>(and I agree that we shouldn't release with that bug, so I agree that
>the severity is correct)?
>
>15 days is a pretty short time for irreversible changes in Debian, IMO.
>
>If the policy for the upcoming release really is (and will remain) "once
>you're out, you stay out, no exceptions", then have fun releasing Debian
>without me.

Fully agreed.

>If the release team is willing to consider exceptions when
>the automated machinery was jumping the gun a little, however, then
>okay, I think it might be a good idea to try this out.

If you only get an exception if your package is so important that the
press will mention us like "Debian stretch is missing the important
foo package", then I wouldn't want to even try this. If getting an
exception is the normal case, then, fine, try it. But why would be
bother to write this in policy if we intend to do this as the normal
case?

I probably will not bother with asking for an exception if I would
need one. If the release team feels like releasing without one of my
packages, I'm fine with that. You're not obliged to take advantage of
my work. Mein Server läuft auch ohne User.

>Being rigid about such policies is never a good thing, though.

Yes. And I am afraid that this policy is being as rigid as a two inch
steel wall.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 6 Nov 2016 12:53:42 +0100, Christian Seiler
 wrote:
>And if the problem is complicated, they have other
>options: request for help on debian-devel@ and debian-mentors@,
>request an exception from the release team to mark a bug as
>stretch-ignore in specific cases, request an extension by the
>release team to delay autoremoval so they have more time to
>fix the issue, etc.

This means that one needs personal sympathy, a thing that many people
don't have. Especially those who have spoken their mind in the past or
have voiced a minority opinion are likely to experience that. I have
always liked in Debian that you don't need to brown-nose the people in
power to have your work appreciated. Sadly, those times seem to be
over.

>If a stable release is going to happen, there needs to be some
>kind of process so that one may converge on a stable result.

I have been around since Debian slink. I have seen train-wreck
releases like sarge. As being around for so long, I have to say that
the last three-or-so releases have been rather smooth and painless,
thanks to the good work the release team and the rest of the Debian
community have done.

Even the systemd migration, which I have predicted as being doomed and
quite painful, went without a hitch. I must say that I have been
really astonished about this and I am proud of being a (tiny and
mostly irrelevant) part of the community that has done so superb work
in the last years. systemd has made us lose valuable people, but we
got even this release out of the door nearly in time and in a
nearly-perfect stage. Well done.

Actually, I am kind of afraid that after we have driven off the people
who complained about us releasing too seldomly with the pre-lenny
releases, we are now driving off the people who complain about us
releasing too often. This effect will be enhanced by the fact that
we're going to release an incomplete stretch this time, with no
mechanism in place that will even tell pre-existing users of a package
that was in jessie but not in stretch that we felt like removing this
package.

That being said, I simply don't see the neccisity of tightening the
thumbscrews on contributors with the new policy. We have done
sufficiently well in the past, and this new policy is not going to
improve this, but au contraire.

>What happens if you only have a single deadline to freeze
>fully? Immediately before that deadline people panic because
>they noticed they didn't take care of their packages enough
>and upload tons of stuff on very short notice - which leads to
>more bugs due to weird interactions that will then have to be
>sorted out during the actual freeze. With the soft deadlines
>added now, this will be relaxed quite a bit, because
>everything doesn't hit at once, but it's spaced out and the
>overall quality will improve.

Agreed.

>I really don't see where you are coming from: why do you think
>this makes things worse?

We will release an incomplete distribution if we don't allow packages
back in. And it will damage our contributor's egos when they get the
information that their package is not important enough to get an
exception, while more important or key packages will _OF_ _COURSE_ be
excempt from this policy. We already have a two-class citizenship in
Debian, this policy is going to introduce a third class.

>The only people affected negatively
>by this are going to be people asleep at the wheel for the
>entire Stretch cycle that only wake up right before the hard
>freeze. And I think that curbing that kind of maintenance
>"style" is a very, very good thing.

I'd rather have a badly maintained package than none.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre 
> wrote:
> >Releasing Debian is work for all of us, not just the Release Team...
> 
> So you are actually suggesting that people who are neither on the
> release team nor maintaining a key package are not working?

He is very obviously not suggesting that. He is just saying what he
said: the Release Team shouldn't be doing all the work to get the thing
out.

Samuel

Re: More 5 november in the release schedule

[Adam D. Barratt]

On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote:
> On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier 
> >"""
> >The release managers may make exceptions to these guidelines as they see
> >fit. *Such exceptions are not precedents and you should not assume that
> >your package has a similar exception*. Please talk to us if you need
> >guidance.unnecessarily 
> >"""
> >(Emphasis from original - 3rd paragraph from the top)
> 
> This is a quite nice opportunity to say something like "you haven't
> been nice enough to us in the past or you have dared to speak up when
> you didn't like what we did, so you're free to take a hike with your
> package, have a nice day".

Only if you start from an assumption of bad faith.

> I find that unnecessarily humiliating and will probably not do this
> and rather live without my package in stable for this release.

I find your characterisation of a team and process I've invested several
years in trying to make the best that we can demotivating, frankly. And
no, I'm not just saying that as tit-for-tat.

Regards,

Adam

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius  wrote:
> >I'm even willing to justify my opinion: Keeping testing in a state
> >that can be released seems to be the only way in which we can make a
> >release in a reasonable time frame. We've tried several other
> >approaches, which haven't worked. The approach of "let's freeze and
> >then try to fix things" didn't work. Let's not try it again.
> 
> I do not think that it is a service to our users to release an
> incomplete distribution just for the sake of keeping a date.

As said above, it's *not* a matter of "keeping a date", but "getting
something out at all within reasonable time".

Samuel

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius  wrote:
>I'm even willing to justify my opinion: Keeping testing in a state
>that can be released seems to be the only way in which we can make a
>release in a reasonable time frame. We've tried several other
>approaches, which haven't worked. The approach of "let's freeze and
>then try to fix things" didn't work. Let's not try it again.

I do not think that it is a service to our users to release an
incomplete distribution just for the sake of keeping a date.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre 
wrote:
>Releasing Debian is work for all of us, not just the Release Team...

So you are actually suggesting that people who are neither on the
release team nor maintaining a key package are not working?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Samuel Thibault]

Marc Haber, on Sun 13 Nov 2016 11:30:18 +0100, wrote:
> On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson
>  wrote:
> >If it turns out to be a more common problem and there are many
> >packages affected, then this would mean delays to the stretch release,
> >indeed. 
> 
> One of my issues is that this new policy means a switch from "we'll
> release when it's ready" to "we'll sacrifice package list completeness
> of our release for a timely release", which is a rather radical
> change.

We have always had to sacrifice packages to get something released. You
can't release 10,000 packages at the same time if you don't make
sacrifices.

It just has moved from "arbitrary" to "not maintain closely enough".

Samuel

Re: More 5 november in the release schedule

[Marc Haber]

On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann 
wrote:
>I don't quite understand where all this fuzz about auto-removals
>suddenly comes from. The auto-removals exist since Septemer 2013 [0]
>and they were also in place for the jessie freeze [1], with the small
>difference that now the point-of-no-return is a month before the hard
>freeze, and in jessie it started with the hard freeze.

If the jessie release actually had a point-of-no-return, then it was
this seldomly and/or silently enforced that I totally missed it.

I don't have anything against autoremovals, I am strongly opposed
against the "once you're out, you'll stay out" since I fail to see the
advantages of this approach aside from "giving incentives".

For me, this "incentive" will most likely have the opposite result.

Greetings
Marc, who is about to stop caring just a bit more
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson
 wrote:
>If it turns out to be a more common problem and there are many
>packages affected, then this would mean delays to the stretch release,
>indeed. 

One of my issues is that this new policy means a switch from "we'll
release when it's ready" to "we'll sacrifice package list completeness
of our release for a timely release", which is a rather radical
change.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier 
wrote:
> * As James noted; sending an update to the bug will reset the timer.

Did I miss the documentation about this? It does not seem to be in the
freeze policy.

> * Also, if you do not have time for a given bug, please consider
>   tagging it "help", so your fellow contributors know that you need
>   help.  That tag shows up on all RC bugs views I know of.

How many bugs tagged help actually go get help?

> * For more extreme cases (death, mowed by bus, sudden long term
>   illness, etc), the replacement maintainer can ask for an exception.
>   (per [freeze policy])

That'll hold for less than a percent of the removals.

>"""
>The release managers may make exceptions to these guidelines as they see
>fit. *Such exceptions are not precedents and you should not assume that
>your package has a similar exception*. Please talk to us if you need
>guidance.
>"""
>(Emphasis from original - 3rd paragraph from the top)

This is a quite nice opportunity to say something like "you haven't
been nice enough to us in the past or you have dared to speak up when
you didn't like what we did, so you're free to take a hike with your
package, have a nice day".

I find that unnecessarily humiliating and will probably not do this
and rather live without my package in stable for this release.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Thu, 10 Nov 2016 08:36:21 +0100, Ole Streicher 
wrote:
>Wouter Verhelst  writes:
>> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>>> 30 days within the deep freeze should be plenty enough - and as I
>>> said: if the problem is more complicated, just talk to the release
>>> team _while the package is still in testing_.
>>
>> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
>> or I get a major project at work which eats up all my time, or whatnot)
>> and I don't notice for a while that a package that I maintain gets an RC
>> bug. The automated machinery throws the package out before I have time
>> to work on the package again. Now what?
>
>This is a good argument for team maintenance. :-)

Why is Libreoffice not team maintained, for example? Where is the KDE
team doing bug triaging? There are less important packages where the
maintainer has been searching for help to work in a team for years
without success.

And instead of relieving those people, they now get responsible for
their dependencies as well if their maintainers are overworked as well
if they want their packages to be in stretch.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Tue, 8 Nov 2016 11:05:59 +0100, Christian Seiler
 wrote:
>Yes, especially since autoremovals are not instantaneous, but for
>packages with rdeps (and the rdeps themselves) will happen at
>least 30 days in the future - and you will get an email in time.
>(For packages without rdeps it's 15 days. Plus IIRC a week delay
>after a bug was initially marked RC before autoremoval is even
>triggered, but I might be wrong about that last part.)
>
>30 days within the deep freeze should be plenty enough

I would feel a lot less uncomfortable if the teams who are using
automated tools to auto-file RC bugs for third-rate policy violations
which will auto-remove a (99,99% of the cases) perfectly working
package from testing in a time where a maintainer would probably not
dare to touch his maintainer scripts for fear of creating a really RC
bug which will in turn get the package auto-removed from testing would
refrain from doing their auto-foo during the freeze.

I do appreciate automated tests, and while I think it can be discussed
whether the policy violations found by those automatic tests need to
be RC, I firmly believe that these tools should not be used as a
weapon against packages.


>- and as I
>said: if the problem is more complicated, just talk to the release
>team _while the package is still in testing_.

So you want people to beg if they want their packages in testing. What
is that going to help, aside from demotivating and humiliating people?

>The goal of autoremovals is to provide an incentive for people
>to deal with problems in their packages _early_.

Managerspeak. Even at work I hate people who talk about giving
"incentives" while they actually threaten.

>And as I said previously: if a maintainer of a dependency of yours
>doesn't care: NMUs for RC bugs have a far lower threshold - even
>0-day NMUs are possible if the maintainer is really completely
>asleep. (DevRef 5.11.1)

So this is a method to force people to take additional
responsibilities for dependencies as well in addition to the
responsibilities they have taken voluntarily? Well, _this_ will
clearly motivate people.

Greetings
Ma "not." rc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule [and 1 more messages]

[Christoph Biedl]

Marc Haber wrote...

> This is exactly the problem I have with the current policy: I fail to
> see why this measure will shorten the freeze.

I don't. But I'd say we'll just watch what's going to happen and resume
this discussion once stretch is released.

Chri- "somewhen December 2017" stoph


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule [and 1 more messages]

[Marc Haber]

On Thu, 10 Nov 2016 10:17:57 +0100, Emilio Pozuelo Monfort
 wrote:
>And yes, we will give exceptions on a case by case basis, as we have always 
>done.

This will create a third class of packages: The ones that are not
important enough to get an exception, which will in turn demotivate
package maintainers even more.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule [and 1 more messages]

[Marc Haber]

On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
 wrote:
>Finally, there's a thing called "trust": I trust the Release Team does
>this solely in order to keep the freeze time as short as possible,
>everybody hates that time anyway. This trust was created by the very
>people behind it, and the way they acted in the past months.

This is exactly the problem I have with the current policy: I fail to
see why this measure will shorten the freeze.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule [and 1 more messages]

[Emilio Pozuelo Monfort]

On 10/11/16 08:26, Christoph Biedl wrote:
> Ian Jackson wrote...
> 
>> I think what is really worrying people is the fear that they might
>> miss something, for good reasons, and then find that their work that
>> they care about is thrown out of stretch.
>>
>> It is difficult to address this fear with logical arguments intended
>> to demonstrate that "it won't happen to a responsible maintainer",
>> because it is so easy to think of scenarios where, at the very least,
>> it's hard to be sure that the right things would happen.
> 
> For me it's a bit different. If John S.(lacker) Maintainer ignored the
> messages about debhelper compat 4 removal for ten and about the
> openssl 1.1 transition for seven months, and in January suddenly finds
> his packages got kicked out and cannot return for stretch - he had it
> coming.
> 
> If however Jane R.(esponsible) Maintainer did everything right but did
> not realize somebody else's non-action affects her packages as well,
> through a build dependency or whatever ... until the "Your package was
> removed from testing" e-mail arrives: That's quite a nuisance.
> 
> So if I, in Jane's position, could be certain I'll learn about a
> pending removal that affects my packages early enough I can avoid this
> (by kicking the maintainer or NMU), my concerns were neglectable. A
> grace period of just a few days was sufficient. This mechanism is
> implemented for install dependencies, but after reading this thread
> I'm not sure it exists for other scenarios as well. 
> 
>> On the other hand, it would be really easy for the Release Team to
>> address this fear.  All they have to say is that if there is a really
>> good excuse (maintainer seriously ill; build-dependency broken and
>> maintainer not notified; or whatever), they will be willing to
>> consider exceptions.
> 
> I guess the Release Team plays tough in the first place so people do
> their job *now* instead of asking for exceptions later. I'd call that
> wise tactics. The e-thing still might happen if there's really, really
> good reason. But creating false hope sends the wrong signal. 
> 
> Finally, there's a thing called "trust": I trust the Release Team does
> this solely in order to keep the freeze time as short as possible,
> everybody hates that time anyway. This trust was created by the very
> people behind it, and the way they acted in the past months.

+1.

And yes, we will give exceptions on a case by case basis, as we have always 
done.

Also, as has been noted in this thread, it looks like some processes could be
improved (e.g. notifying rdeps when removing a package from unstable). Let's see
what affects the release process and then let's try to improve those things.

Cheers,
Emilio

Re: More 5 november in the release schedule

[Ole Streicher]

Wouter Verhelst  writes:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
>
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

This is a good argument for team maintenance. :-)

Cheers

Ole

Re: More 5 november in the release schedule

[Niels Thykier]

Wouter Verhelst:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
> 
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?
> 
> What if I did notice, but fixing the bug takes longer than the 15 days
> (and I agree that we shouldn't release with that bug, so I agree that
> the severity is correct)?
> 

I appreciate that you are concerned.  However, I think most people and
their packages go through the freeze just fine.

 * As James noted; sending an update to the bug will reset the timer.
   (Update early, update often - last minute pings might not make it in
time)

 * Also, if you do not have time for a given bug, please consider
   tagging it "help", so your fellow contributors know that you need
   help.  That tag shows up on all RC bugs views I know of.

 * For more extreme cases (death, mowed by bus, sudden long term
   illness, etc), the replacement maintainer can ask for an exception.
   (per [freeze policy])


Thanks,
~Niels



[freeze policy]:

"""
The release managers may make exceptions to these guidelines as they see
fit. *Such exceptions are not precedents and you should not assume that
your package has a similar exception*. Please talk to us if you need
guidance.
"""
(Emphasis from original - 3rd paragraph from the top)

https://release.debian.org/stretch/freeze_policy.html

Re: More 5 november in the release schedule [and 1 more messages]

[Christoph Biedl]

Ian Jackson wrote...

> I think what is really worrying people is the fear that they might
> miss something, for good reasons, and then find that their work that
> they care about is thrown out of stretch.
>
> It is difficult to address this fear with logical arguments intended
> to demonstrate that "it won't happen to a responsible maintainer",
> because it is so easy to think of scenarios where, at the very least,
> it's hard to be sure that the right things would happen.

For me it's a bit different. If John S.(lacker) Maintainer ignored the
messages about debhelper compat 4 removal for ten and about the
openssl 1.1 transition for seven months, and in January suddenly finds
his packages got kicked out and cannot return for stretch - he had it
coming.

If however Jane R.(esponsible) Maintainer did everything right but did
not realize somebody else's non-action affects her packages as well,
through a build dependency or whatever ... until the "Your package was
removed from testing" e-mail arrives: That's quite a nuisance.

So if I, in Jane's position, could be certain I'll learn about a
pending removal that affects my packages early enough I can avoid this
(by kicking the maintainer or NMU), my concerns were neglectable. A
grace period of just a few days was sufficient. This mechanism is
implemented for install dependencies, but after reading this thread
I'm not sure it exists for other scenarios as well. 

> On the other hand, it would be really easy for the Release Team to
> address this fear.  All they have to say is that if there is a really
> good excuse (maintainer seriously ill; build-dependency broken and
> maintainer not notified; or whatever), they will be willing to
> consider exceptions.

I guess the Release Team plays tough in the first place so people do
their job *now* instead of asking for exceptions later. I'd call that
wise tactics. The e-thing still might happen if there's really, really
good reason. But creating false hope sends the wrong signal. 

Finally, there's a thing called "trust": I trust the Release Team does
this solely in order to keep the freeze time as short as possible,
everybody hates that time anyway. This trust was created by the very
people behind it, and the way they acted in the past months.

Christoph


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[James McCoy]

On Thu, Nov 10, 2016 at 12:24:20AM +0100, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> > 30 days within the deep freeze should be plenty enough - and as I
> > said: if the problem is more complicated, just talk to the release
> > team _while the package is still in testing_.
> 
> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

If I understand correctly, activity on the bug resets the counter, so
you could ping it to say that you're busy right now but will look at it
in a few days or some such.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, 2016-11-09 at 22:55 +0200, Adrian Bunk wrote:

> Is anyone tracking what packages are installed from backports on
> Debian machines, and the CVEs in them?

backports is unsupported by the security team, so DSA & backports users
rely on service maintainers and backporters to do the right thing.

> Using backports without doing that would be irresponsible.

Agreed, but that is the best we have right now.

> Package removals from unstable are also a potential problem, example:

Agreed.

> The maintainer wanted to remove this package from *unstable*.

Thanks for pointing this out.

> FreeRADIUS is popular enough that people noticed before an RM: bug was 
> filed, and new maintainers were found immediately.

Looks like that wasn't enough since it didn't reach unstable yet.

> Other packages are not that popular.

Even the unpopular packages have users or potential users, we need to
develop better chains of communication with those users & communities.

> If any packages needed on these Debian machines have been removed from 
> unstable, they are not on your list.

Correct:

https://bugs.debian.org/838363
  
> This is the reason why a ITP/RM revolving door is creating huge 
> headaches for users.

Agreed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: More 5 november in the release schedule [and 1 more messages]

[Ian Jackson]

gregor herrmann writes ("Re: More 5 november in the release schedule"):
> I don't quite understand where all this fuzz about auto-removals
> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
> and they were also in place for the jessie freeze [1], with the small
> difference that now the point-of-no-return is a month before the hard
> freeze, and in jessie it started with the hard freeze.

The fuss is happening because we're in a freeze again, and because a
different group of people happen to be paying attention to these
discussions.

> In my experience, auto-removals before and during the jessie freeze
> were very helpful to keep the freeze shorter than previous ones.
> Personally, I'm not looking back to the releases were we spent month
> fixing RC bugs in packages that noone cared about; with the
> auto-removals from testing, they are no blockers anymore.

Few people (if any) in this thread has suggested that the autoremovals
are a bad idea.  Most people even seem to be in favour of the "no
return" idea.

I think what is really worrying people is the fear that they might
miss something, for good reasons, and then find that their work that
they care about is thrown out of stretch.

It is difficult to address this fear with logical arguments intended
to demonstrate that "it won't happen to a responsible maintainer",
because it is so easy to think of scenarios where, at the very least,
it's hard to be sure that the right things would happen.

On the other hand, it would be really easy for the Release Team to
address this fear.  All they have to say is that if there is a really
good excuse (maintainer seriously ill; build-dependency broken and
maintainer not notified; or whatever), they will be willing to
consider exceptions.

Wouter Verhelst writes ("Re: More 5 november in the release schedule"):
> [...]  If the release team is willing to consider exceptions when
> the automated machinery was jumping the gun a little, however, then
> okay, I think it might be a good idea to try this out.

We tried this with jessie and it worked well.

> Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
> or I get a major project at work which eats up all my time, or whatnot)
> and I don't notice for a while that a package that I maintain gets an RC
> bug. The automated machinery throws the package out before I have time
> to work on the package again. Now what?

If your lifestyle means that you might not notice such an RC bug
because you're on holiday for two weeks, or because of a work crisis,
then there is an overall problem: your packages might actually cause
trouble (and work) for other contributors who are trying to release.

If this happens to you, please find someone to pay attention to your
packages in the meantime.  Have them subscribe to the PTS and/or look
at your DDPO.[1]

Of course if you are hit by a bus or something then I hope the release
team would be flexible.

Thanks,
Ian.

[1] I'm volunteering, provided this is an "I'm going hiking for three
weeks in the Scottish Highlands" thing, with defined dates, not a
"please permanently add this to your todo list" thing.

If you have such work crises that you will miss RC bug emails and
autoremovals, you should work on your email filtering.  Once you know
about the bug you can ask for help, of course.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: More 5 november in the release schedule

[Wouter Verhelst]

On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> 30 days within the deep freeze should be plenty enough - and as I
> said: if the problem is more complicated, just talk to the release
> team _while the package is still in testing_.

Let's say I'm on holiday (or I get hit by a bus and end up in hospital,
or I get a major project at work which eats up all my time, or whatnot)
and I don't notice for a while that a package that I maintain gets an RC
bug. The automated machinery throws the package out before I have time
to work on the package again. Now what?

What if I did notice, but fixing the bug takes longer than the 15 days
(and I agree that we shouldn't release with that bug, so I agree that
the severity is correct)?

15 days is a pretty short time for irreversible changes in Debian, IMO.

If the policy for the upcoming release really is (and will remain) "once
you're out, you stay out, no exceptions", then have fun releasing Debian
without me. If the release team is willing to consider exceptions when
the automated machinery was jumping the gun a little, however, then
okay, I think it might be a good idea to try this out.

Being rigid about such policies is never a good thing, though.

> The goal of autoremovals is to provide an incentive for people
> to deal with problems in their packages _early_. My experience
> with the release team is that they are very willing to consider
> many different solutions if you talk to them early enough. They
> just don't want people coming along 4 months into the freeze and
> telling them "er, yeah, my package got removed 3 months ago, and
> I just didn't care about it until now, and during the entire
> freeze it didn't really receive much testing, but pretty please
> could it be included again?"

Well, yes, that makes sense -- but there's a major difference between "I
didn't care about my packages for 3 months" and "I didn't have time for
in-depth work for more than two weeks". The former marks an inactive
maintainer; The latter is not uncommon (at least for me).

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: More 5 november in the release schedule

[Adrian Bunk]

On Wed, Nov 09, 2016 at 11:16:36AM +0800, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
> > Right. We want auto-removals to be useful for the release process, so that 
> > we
> > don't end up with a thousand of RC bugs in testing when we freeze, most of 
> > them
> > on packages that nobody cares about, not even their maintainers.
> >
> > However, we don't want auto-removals to drop your package behind your back. 
> > If
> > that happens, that's a bad thing and you should let us know so we can fix
> > things. auto-removals should notify the maintainer in advance, and only act
> > after a reasonable period of time.
> >
> > The "packages can't re-enter testing during the freeze" is an incentive so 
> > that
> > maintainers don't wait to fix a package after a few months, and so that we 
> > don't
> > have to go and remove them manually. This way you know that something is 
> > going
> > to happen if you don't act, yet you should have a reasonable amount of time 
> > to
> > do something. Hopefully this helps have a short(er) freeze, which is good 
> > for
> > everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports

Is anyone tracking what packages are installed from backports on
Debian machines, and the CVEs in them?

Using backports without doing that would be irresponsible.

> as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
>...

Package removals from unstable are also a potential problem, example:

==> vogler.debian.org <==
New packages removed from Debian 'testing' (the maintainer might need help):
 - freeradius - https://tracker.debian.org/pkg/freeradius
 - freeradius-common - https://tracker.debian.org/pkg/freeradius
 - freeradius-utils - https://tracker.debian.org/pkg/freeradius
 - libfreeradius2 - https://tracker.debian.org/pkg/freeradius

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806617#22
The maintainer wanted to remove this package from *unstable*.

FreeRADIUS is popular enough that people noticed before an RM: bug was 
filed, and new maintainers were found immediately.
Other packages are not that popular.

If any packages needed on these Debian machines have been removed from 
unstable, they are not on your list.

This is the reason why a ITP/RM revolving door is creating huge 
headaches for users.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: More 5 november in the release schedule

[gregor herrmann]

On Wed, 09 Nov 2016 14:01:13 +, Ian Jackson wrote:

> If it turns out to be a more common problem and there are many
> packages affected, then this would mean delays to the stretch release,
> indeed.  But it would also highlight where the real problem is - ie,
> not with the maintenance of the individual packages, but with our
> processes for ensuring that the right information gets to the right
> people.  If this _is_ a problem for stretch then we need to improve
> our processes for buster, rather than throwing stuff out of stretch.

I don't quite understand where all this fuzz about auto-removals
suddenly comes from. The auto-removals exist since Septemer 2013 [0]
and they were also in place for the jessie freeze [1], with the small
difference that now the point-of-no-return is a month before the hard
freeze, and in jessie it started with the hard freeze.

In my experience, auto-removals before and during the jessie freeze
were very helpful to keep the freeze shorter than previous ones.
Personally, I'm not looking back to the releases were we spent month
fixing RC bugs in packages that noone cared about; with the
auto-removals from testing, they are no blockers anymore.


Cheers,
gregor


[0] https://lists.debian.org/debian-devel-announce/2013/09/msg6.html
[1] https://release.debian.org/jessie/freeze_policy.html#autoremovals

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Claudine2


signature.asc
Description: Digital Signature

Re: More 5 november in the release schedule

[Ian Jackson]

Marvin Renich writes ("Re: More 5 november in the release schedule"):
> Emilio Pozuelo Monfort <po...@debian.org> [161108 16:01]:
> > It is true for other removals from testing, which can happen in two 
> > different ways:
> > 
> > - The package was removed from unstable
> > - The package was hinted for testing removal by the release team
> > 
> > Since britney doesn't enforce (atm) that build-dependencies are
> > satisfiable in testing, those two cases can cause this
> > problem. However in the former case, rdeps should get a FTBFS bug
> > so you will know about the problem, and the latter is not very
> > frequent.
> 
> But wouldn't the FTBFS bug be filed after the removal of the build-dep,
> so that it is too late for the maintainer to assist in keeping the
> build-dep in the archive?  I thought this part of the thread was about
> getting notification of pending, not already happened, removals so that
> help could be directed in time to keep the package in the archive.  Do I
> misunderstand?

We've discussed several corner cases here and it's still not quite
clear if a maintainer would always get an appropriate heads-up.

It would be helpful if the release team would confirm that if

 - a contributor is trying to keep a package in testing;

 - the contributor has paid reasonable attention to the available
   information channels (tracker.d.o, PTS subscription, BTS, say) for
   the package they care about, but these did not provide timely
   notification that the package was at risk of falling out of
   stretch;

 - the contributor fixes the underlying issue(s) expeditiously;

the Release Team would consider favourably a request for an exception
(to whatever policies stand in the way of fixing the problem in
stretch).

I think such a statement would greatly alleviate some of the concerns
we have seen here.  It would be valuable for this reason even if we
currently think that such a scenario is very unlikely in practice.

If it turns out to be a more common problem and there are many
packages affected, then this would mean delays to the stretch release,
indeed.  But it would also highlight where the real problem is - ie,
not with the maintenance of the individual packages, but with our
processes for ensuring that the right information gets to the right
people.  If this _is_ a problem for stretch then we need to improve
our processes for buster, rather than throwing stuff out of stretch.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: More 5 november in the release schedule

[Marvin Renich]

* Emilio Pozuelo Monfort  [161108 16:01]:
> It is true for other removals from testing, which can happen in two different 
> ways:
> 
> - The package was removed from unstable
> - The package was hinted for testing removal by the release team
> 
> Since britney doesn't enforce (atm) that build-dependencies are satisfiable in
> testing, those two cases can cause this problem. However in the former case,
> rdeps should get a FTBFS bug so you will know about the problem, and the 
> latter
> is not very frequent.

But wouldn't the FTBFS bug be filed after the removal of the build-dep,
so that it is too late for the maintainer to assist in keeping the
build-dep in the archive?  I thought this part of the thread was about
getting notification of pending, not already happened, removals so that
help could be directed in time to keep the package in the archive.  Do I
misunderstand?

...Marvin

Re: More 5 november in the release schedule

[Simon McVittie]

On Wed, 09 Nov 2016 at 17:03:45 +1100, Brian May wrote:
> Another situation: You are not listed as the maintainer of the package
> you really care about, and the real maintainer ignores the autoremoval
> notifications. Other people looking at the package bug reports (there
> may be none) may not realize it is pending autoremoval.

I would recommend  for all your
"what is going on with this package?" needs. (I have a shortcut for it
set up in my browser, so I just type "debpts hello" into the URL bar -
the name is leftover muscle-memory from when the shortcut sent me to the
older PTS interface .)

If you particularly care about a package, subscribing to it (also available
from the tracker) will get you the same notifications that maintainers get.
I am not actually the Maintainer of record for most of my packages
(because they're team-maintained and I'm just an Uploader) so I rely on
this for normal maintenance.

S

Re: More 5 november in the release schedule

[Emilio Pozuelo Monfort]

On 09/11/16 04:16, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
>> Right. We want auto-removals to be useful for the release process, so that we
>> don't end up with a thousand of RC bugs in testing when we freeze, most of 
>> them
>> on packages that nobody cares about, not even their maintainers.
>>
>> However, we don't want auto-removals to drop your package behind your back. 
>> If
>> that happens, that's a bad thing and you should let us know so we can fix
>> things. auto-removals should notify the maintainer in advance, and only act
>> after a reasonable period of time.
>>
>> The "packages can't re-enter testing during the freeze" is an incentive so 
>> that
>> maintainers don't wait to fix a package after a few months, and so that we 
>> don't
>> have to go and remove them manually. This way you know that something is 
>> going
>> to happen if you don't act, yet you should have a reasonable amount of time 
>> to
>> do something. Hopefully this helps have a short(er) freeze, which is good for
>> everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
> 
> I guess alioth will remain on wheezy too.

dose3 is fixed now, so that's not a problem anymore. I have no idea about the
others, but I'm happy to see that respighi is not on that list!

Emilio

Re: More 5 november in the release schedule

[Brian May]

Scott Kitterman  writes:

> I seem to get email when a package I maintain is marked for autoremoval 
> (regardless of whether it is an issue with my package or an rdepend).  That 
> and it showing up on your DDPO Packages overview ought to be enough to be 
> forewarned, I would have thought.

That will help in some cases, but not all cases.

Can't remember what happened for my particular cases. I should look up
the details and refresh my memory, but out of time now.

One situation I can think of: If for example the package is not yet in
testing, you will not get notified that it depends on a broken package
and as such will not get into testing. So you can mistakenly think it is
a simple package, it has no bugs, and not realize it isn't in testing.

Another situation: You are not listed as the maintainer of the package
you really care about, and the real maintainer ignores the autoremoval
notifications. Other people looking at the package bug reports (there
may be none) may not realize it is pending autoremoval.
-- 
Brian May 

Re: More 5 november in the release schedule

[Paul Wise]

On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:

> Right. We want auto-removals to be useful for the release process, so that we
> don't end up with a thousand of RC bugs in testing when we freeze, most of 
> them
> on packages that nobody cares about, not even their maintainers.
>
> However, we don't want auto-removals to drop your package behind your back. If
> that happens, that's a bad thing and you should let us know so we can fix
> things. auto-removals should notify the maintainer in advance, and only act
> after a reasonable period of time.
>
> The "packages can't re-enter testing during the freeze" is an incentive so 
> that
> maintainers don't wait to fix a package after a few months, and so that we 
> don't
> have to go and remove them manually. This way you know that something is going
> to happen if you don't act, yet you should have a reasonable amount of time to
> do something. Hopefully this helps have a short(er) freeze, which is good for
> everyone.

FYI, it looks like at least buildd stuff (IIRC that uses dose3),
rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
on jessie until the affected packages reach stretch-backports as a
result of the autoremovals stuff:

https://lists.debian.org/debian-services-admin/2016/10/msg2.html

I guess alioth will remain on wheezy too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

[Christian Seiler]

On 11/08/2016 08:47 PM, Adrian Bunk wrote:
> On Tue, Nov 08, 2016 at 02:31:04AM -0500, Scott Kitterman wrote:
>> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>>> Christian Seiler  writes:
 Why? Any package currently in testing still has time to enter
 (until roughly end of this year), so it's not like there is no
 heads-up for people. And RC bugs don't lead to immediate
 removal from testing, you still have quite a bit of time until
 they actually cause removal of a package.
>>>
>>> The problem is if the maintainer is not responding to RC bug reports,
>>> and you don't realize a package you depend on has RC bugs. This happened
>>> several times to me during the last freeze.
>>
>> I seem to get email when a package I maintain is marked for autoremoval 
>> (regardless of whether it is an issue with my package or an rdepend).  That 
>> and it showing up on your DDPO Packages overview ought to be enough to be 
>> forewarned, I would have thought.
> 
> For dependencies that is correct.
> 
> But there is currently no kind of notification in place if a 
> build-dependency of your package is scheduled for autoremoval.
> 
> When a build dependency of your package is actually removed from 
> testing, you are also not getting any notification.
> 
> If your build dependency gets removed from testing on Christmas Day
> or later, your package will anyway not be in stretch.

Then this just means that autoremovals should not only take
into account dependencies but also build dependencies,
because then the maintainer would be notified of that fact.

Regards,
Christian

Re: More 5 november in the release schedule

[Christian Seiler]

On 11/08/2016 08:31 AM, Scott Kitterman wrote:
> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>> Christian Seiler  writes:
>>> Why? Any package currently in testing still has time to enter
>>> (until roughly end of this year), so it's not like there is no
>>> heads-up for people. And RC bugs don't lead to immediate
>>> removal from testing, you still have quite a bit of time until
>>> they actually cause removal of a package.
>>
>> The problem is if the maintainer is not responding to RC bug reports,
>> and you don't realize a package you depend on has RC bugs. This happened
>> several times to me during the last freeze.
> 
> I seem to get email when a package I maintain is marked for autoremoval 
> (regardless of whether it is an issue with my package or an rdepend).  That 
> and it showing up on your DDPO Packages overview ought to be enough to be 
> forewarned, I would have thought.

Yes, especially since autoremovals are not instantaneous, but for
packages with rdeps (and the rdeps themselves) will happen at
least 30 days in the future - and you will get an email in time.
(For packages without rdeps it's 15 days. Plus IIRC a week delay
after a bug was initially marked RC before autoremoval is even
triggered, but I might be wrong about that last part.)

30 days within the deep freeze should be plenty enough - and as I
said: if the problem is more complicated, just talk to the release
team _while the package is still in testing_.

The goal of autoremovals is to provide an incentive for people
to deal with problems in their packages _early_. My experience
with the release team is that they are very willing to consider
many different solutions if you talk to them early enough. They
just don't want people coming along 4 months into the freeze and
telling them "er, yeah, my package got removed 3 months ago, and
I just didn't care about it until now, and during the entire
freeze it didn't really receive much testing, but pretty please
could it be included again?"

And as I said previously: if a maintainer of a dependency of yours
doesn't care: NMUs for RC bugs have a far lower threshold - even
0-day NMUs are possible if the maintainer is really completely
asleep. (DevRef 5.11.1)

Regards,
Christian

Re: More 5 november in the release schedule

[Scott Kitterman]

On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
> Christian Seiler  writes:
> > Why? Any package currently in testing still has time to enter
> > (until roughly end of this year), so it's not like there is no
> > heads-up for people. And RC bugs don't lead to immediate
> > removal from testing, you still have quite a bit of time until
> > they actually cause removal of a package.
> 
> The problem is if the maintainer is not responding to RC bug reports,
> and you don't realize a package you depend on has RC bugs. This happened
> several times to me during the last freeze.

I seem to get email when a package I maintain is marked for autoremoval 
(regardless of whether it is an issue with my package or an rdepend).  That 
and it showing up on your DDPO Packages overview ought to be enough to be 
forewarned, I would have thought.

Scott K

Re: More 5 november in the release schedule

[Paul Wise]

On Tue, Nov 8, 2016 at 3:19 PM, Brian May wrote:

> The problem is if the maintainer is not responding to RC bug reports,
> and you don't realize a package you depend on has RC bugs. This happened
> several times to me during the last freeze.

Assuming you have your package and its dependencies and
build-dependencies installed, running how-can-i-help will show you the
relevant RC bugs and removals.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: More 5 november in the release schedule

[Brian May]

Christian Seiler  writes:

> Why? Any package currently in testing still has time to enter
> (until roughly end of this year), so it's not like there is no
> heads-up for people. And RC bugs don't lead to immediate
> removal from testing, you still have quite a bit of time until
> they actually cause removal of a package.

The problem is if the maintainer is not responding to RC bug reports,
and you don't realize a package you depend on has RC bugs. This happened
several times to me during the last freeze.
-- 
Brian May 

Re: More 5 november in the release schedule

[Samuel Thibault]

Christoph Biedl, on Mon 07 Nov 2016 19:02:17 +0100, wrote:
> If I understood some remarks in IRC correctly: Filing an RC bug after
> hard freeze may lead to immediate and thus irrevocable removal from
> stretch[citation needed].

The removal is not immediate, you have time to downgrade the severity of
the bug.

Samuel

Re: More 5 november in the release schedule

[Jonas Smedegaard]

Quoting Christoph Biedl (2016-11-07 19:02:17)
> If I understood some remarks in IRC correctly: Filing an RC bug after 
> hard freeze may lead to immediate and thus irrevocable removal from 
> stretch[citation needed]. If this was true, a malicious attacker could 
> abuse this to kick arbitrary packages through exaggerated bug 
> severities. I fail to believe this would really work.

I believe such cases are best addressed by simply requesting the release 
team to consider override their automated machinery.

I guess their automated routines are intended as an aid in a) reduce 
manual work and b) reduce disputes by making general logic transparent, 
but not (at least yet) for the processing to be fully automatic.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: More 5 november in the release schedule

[Christoph Biedl]

Ian Jackson wrote...

> There's still big spikes in work for our core teams around deadlines,
> so it's still best if people sort their stuff out earlier, but the new
> arrangements are a big improvement IMO.

ACK, and also looking at the way removals were handled in the past
months (Like long grace periods and lots of warnings), I am very
confident the release team will handle stretch in a sane and also
sensible way.


If I understood some remarks in IRC correctly: Filing an RC bug after
hard freeze may lead to immediate and thus irrevocable removal from
stretch[citation needed]. If this was true, a malicious attacker could
abuse this to kick arbitrary packages through exaggerated bug
severities. I fail to believe this would really work.

Christoph


signature.asc
Description: Digital signature

Re: More 5 november in the release schedule

[Ian Jackson]

Christian Seiler writes ("Re: More 5 november in the release schedule"):
> If a stable release is going to happen, there needs to be some
> kind of process so that one may converge on a stable result.
> What happens if you only have a single deadline to freeze
> fully? Immediately before that deadline people panic because
> they noticed they didn't take care of their packages enough
> and upload tons of stuff on very short notice - which leads to
> more bugs due to weird interactions that will then have to be
> sorted out during the actual freeze. With the soft deadlines
> added now, this will be relaxed quite a bit, because
> everything doesn't hit at once, but it's spaced out and the
> overall quality will improve.

I agree.

The new system of soft deadlines, autoremoval, etc., creates an
environment where natural human tendencies amongst our contributors
(like doing stuff at the last minute) lead to constructive, rather
than unconstructive actions by those contributors.

There's still big spikes in work for our core teams around deadlines,
so it's still best if people sort their stuff out earlier, but the new
arrangements are a big improvement IMO.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: More 5 november in the release schedule

[Christian Seiler]

On 11/06/2016 11:59 AM, Marc Haber wrote:
> On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier 
> wrote:
>> Marc Haber:
>>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>>>  wrote:
 [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
   migrations)
>>>
>>> Does this really mean "once you're out, you'll stay out"?
>>>
>> Yes.
> 
> That is really really bad.

Why? Any package currently in testing still has time to enter
(until roughly end of this year), so it's not like there is no
heads-up for people. And RC bugs don't lead to immediate
removal from testing, you still have quite a bit of time until
they actually cause removal of a package. That means that even
if someone reports an RC bug after the soft freeze maintainers
(and even other people, RC-bugs have a lower NMU threshold)
should have enough time to fix that before the package gets
removed. And if the problem is complicated, they have other
options: request for help on debian-devel@ and debian-mentors@,
request an exception from the release team to mark a bug as
stretch-ignore in specific cases, request an extension by the
release team to delay autoremoval so they have more time to
fix the issue, etc.

If a stable release is going to happen, there needs to be some
kind of process so that one may converge on a stable result.
What happens if you only have a single deadline to freeze
fully? Immediately before that deadline people panic because
they noticed they didn't take care of their packages enough
and upload tons of stuff on very short notice - which leads to
more bugs due to weird interactions that will then have to be
sorted out during the actual freeze. With the soft deadlines
added now, this will be relaxed quite a bit, because
everything doesn't hit at once, but it's spaced out and the
overall quality will improve.

I really don't see where you are coming from: why do you think
this makes things worse? The only people affected negatively
by this are going to be people asleep at the wheel for the
entire Stretch cycle that only wake up right before the hard
freeze. And I think that curbing that kind of maintenance
"style" is a very, very good thing.

Regards,
Christian

Re: More 5 november in the release schedule

[Steve McIntyre]

Marc Haber wrote:
>On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier 
>wrote:
>>Marc Haber:
>>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>>>  wrote:
 [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
   migrations)
>>> 
>>> Does this really mean "once you're out, you'll stay out"?
>>> 
>>Yes.
>
>That is really really bad. I really hoped back in 2015 that you were
>joking when you announced that.

Which packages in particular are you planning to ignore and get
dropped out of the release?

Releasing Debian is work for all of us, not just the Release Team...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: More 5 november in the release schedule

[Lars Wirzenius]

On Sun, Nov 06, 2016 at 11:59:34AM +0100, Marc Haber wrote:
> That is really really bad. I really hoped back in 2015 that you were
> joking when you announced that.

It's really, really good. I was really glad that it isn't a joke.

I'm even willing to justify my opinion: Keeping testing in a state
that can be released seems to be the only way in which we can make a
release in a reasonable time frame. We've tried several other
approaches, which haven't worked. The approach of "let's freeze and
then try to fix things" didn't work. Let's not try it again.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: More 5 november in the release schedule

[Marc Haber]

On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier 
wrote:
>Marc Haber:
>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>>  wrote:
>>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>>>   migrations)
>> 
>> Does this really mean "once you're out, you'll stay out"?
>> 
>Yes.

That is really really bad. I really hoped back in 2015 that you were
joking when you announced that.

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Marc Haber]

On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
 wrote:
> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>   migrations)

Does this really mean "once you're out, you'll stay out"?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: More 5 november in the release schedule

[Niels Thykier]

Marc Haber:
> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>  wrote:
>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>>   migrations)
> 
> Does this really mean "once you're out, you'll stay out"?
> 
> Greetings
> Marc
> 

Yes.

Re: More 5 november in the release schedule

[Sebastiaan Couwenberg]

On 11/05/2016 01:39 PM, Geert Stappers wrote:
> Today is november fifth, day of the soft freeze in the Debian release 
> schedule.

The soft freeze was moved to January 5th, today is the day of the
transition freeze:

"
 Key release dates

 [2016-Nov-05] Transition freeze
 [2016-Dec-05] Mandatory 10-day migrations
 [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
   migrations)
 [2017-Feb-05] Full freeze

 As always, Debian 9 "Stretch" will be released "when it's ready".
"

https://release.debian.org/

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

More 5 november in the release schedule

[Geert Stappers]

Hi,

(At the time of writing, it was 5 november in all timezones)


Today is november fifth, day of the soft freeze in the Debian release schedule.

I real like this fixed date. Having a clear goal is good!
Riding with "Remember, remember, the fifth of november" is cool.


Will Debian release cycles get more fixed dates?

I'm aware it conflicts the "We ship when it ready",
but I'm talking about planning.


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature