Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hey,
On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes <luk@debian.org> wrote:
> IMHO, what is missing from rolling should be added to testing, not
> worked around by introducing another suite:
I believe it's the other way around, actually. To me, adding stuff to
testing is the workaround. Testing is not meant to be used like a
rolling release distribution, as it is based on a set of constraints
which do not have anything to do with rolling releases and constantly
reasonably up-to-date distributions. And that's why it rears its ugly
head (generally by freeze time) for users which were expecting it to
be a rolling-like distribution.
>> How can we ensure that testing always contains a stable version of
>> chromium ? The current decision of keeping it out of testing was right
>> given our actual constraints on what's ok for a stable release.
>> I would argue that we need to redefine our criteria for a stable release
>> and I plan to have this discussion at some point but I think in the mean
>> time having rolling is good way to fix this.
>
> I'd rather fix this so chromium can be added to testing and stable.
And how can that be done? Chromium can't go into stable, so it must be
removed from testing as the product of testing is stable. People have
suggested backports and volatile, but I see those solutions as an
afterthought.
>> How can we ensure that testing continues to be updated during
>> freeze time ? This one is really not fixable without a second
>> distribution. I know it's also the most problematic aspect for the release
>> team because you fear that it will make people care less about getting a
>> stable release out of the door. I think this fear is not completely
>> justified, people that do not care do not need an excuse to not care, they
>> already do it (unfortunately).
>
> I think this is completely the wrong question, we'd better ask the
> question: Why do freezes have to take that long? I do think it's
> completely wrong to have the people causing the long freezes benefit
> from another suite which fits better with not really caring about
> stable, I'd rather have some peer pressure to have a constantly usable
> testing which can be released fast (aka without a long freeze being
> necessary). I do think having snapshots could help with that goal.
I agree that having much shorter freezes would make the situation a
lot better and I do believe that snapshots could provide some sort of
quality assurance that would help shorten freezes. This does not solve
the other issues with using testing the way many people use it
nowadays.
>> Why would non-frequent snapshots help more than frequent snapshots?
>
> Because in that case they could really be used and supported for
> installing, better user testing, security...
I think it kind of depends on how the CUT team plans to assure some
level of quality to the snapshots. If it's just about automated
testing and minimal user intervention (as hinted in the BoF video), I
don't see why non-frequent snapshots would be a requirement.
> Right, though I don't see the need for rolling in this situation unless
> we want to keep long freezes and half baked solutions for difficult to
> support packages. I'd rather have these issues fixed than worked
> around... and I hope many people support that?
Testing or unstable only exist to support stable. Stable is the final
product, testing and unstable are byproducts which people aren't
supposed to use unless they're trying to improve the next stable in
some way. I think what the CUT team is trying to achieve is to make
testing or the rolling suite a first-class citizen and I really like
that idea.
I'm under the impression that some (most?) developers care at least as
much about testing and unstable as they care about stable, as they use
testing or unstable on a daily basis in their machines. Some may be
afraid that a rolling release model would mean some maintainers aren't
going to care about stable anymore. I think this is a valid point, but
preventing maintainers from working on what they care about doesn't
seem right and might actually stray maintainers away from the project.
Who knows, maybe having a rolling suite would even allow us to
"unfork" some Debian derivatives.
Regards,
Reply to: