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

Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)

Hi Luk,

thanks for your valuable comments.

On Sun, 26 Sep 2010, Luk Claes wrote:
> Of course there are multiple reasons. Though I think one of the most
> obvious ones is that we as a project don't do a genuine stable release
> often so sometimes delay the freeze willingly or not. Another reason
> IMHO is that instead of working together and sharing the responsability
> for a release we often tend to do the opposite: by not having clear and
> timely communication on one hand and by trying to get the latest and
> greatest last minute at the other hand.

I think that having an official "rolling" release always available would
reduce the pressure of maintainers to always push the latest into the next
stable release precisely because there's an alternative... so it would
rather help concerning this point.

We can surely do better in terms of length of freeze and better
communication is surely important in the whole picture. "Not having
rolling" does not seem something that will help. I can understand the fear
but IMO it's not based on anything concrete.

> I think we as Release Team should work on having better communication
> with the project on timings of freezes and on why and how some decisions
> are made. I also think we should evolve to having more responsability to
> packaging teams and maintainers to choose the versions they want to help
> support for a longer time.

Full ack.

> On the other hand I hope packagers could refrain from trying to have
> last minute changes and help on fixing the remaining issues faster.

Fixing remaining issues is a general QA problem. We must do more
prevention so that unmaintained packages are not discovered only during
freeze when it's too late but way sooner.

Again it's unrelated to the existence of rolling, the problem is inactive
maintainer not taking care of their packages and those are not the same
that would actively push their packages to rolling.

Those maintainers have package that have not migrated to testing for a
long time usually.

> No, I surely cannot disagree atm. Though I do not want to promote
> another suite which in effect shifts the attention even more from the
> testing suite.

This fear is unjustified. The consequences are much more complicated than
this. It might attract more contributors from derivatives which would
benefic for the general quality and thus the freeze time. Or it might
mean more users who discover the RC bugs quicker than we're doing right
now with testing... etc.

I can understand your fear but I think it's wrong to be opposed to the
rolling idea on the sole ground that it might meant less people caring
about a stable release.

Of course, we must design rolling in a way that it supports testing and
vice-versa. In the mid-long term, they might merge again but right now
it's easier to start with a new release where we can experiment a bit
rather than push important changes to the current release process.

Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Reply to: