Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Raphael
On 09/26/2010 08:40 PM, Raphael Hertzog wrote:
> 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 do already have experimental.
>> 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.
Indeed, so I'm not arguing against having more testing of testing with
snapshots.
> 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.
What do you base this on? It does not at all seem clear to me that
rolling would not introduce maintainers who only care about rolling.
> Those maintainers have package that have not migrated to testing for a
> long time usually.
Right, though inactive maintainers are not usually the problem as they
can be worked around (NMU).
>> 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.
It might also attract more users that file bugs that are already fixed
or that were never in unstable nor testing. I still fail to see why the
problems with testing have to be worked around at instead of be fixed
properly.
> 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.
It's not only that, but also the fear that the problems we do have with
testing will stay instead of getting fixed properly...
I think it's great to have discussion about the issues and even about
possible solutions, though I don't think we should try to be hasty nor
introduce extra suites to work around issues we are having with suites
we have today.
> 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.
Are you talking about introducing rolling during the current freeze? I
think that would only prove my point that it shifts attention away from
testing... Besides we still need to fix the current issue we have with
chromium and similar packages before the release...
Cheers
Luk
Reply to: