Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/26/2010 05:02 PM, Fernando Lemos wrote:
> On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes <luk@debian.org> wrote:
>>> 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'd rather see them as a kind of mini releases instead.
>> 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.
Right, though I'd rather have testing usable all the time than having an
extra suite which will cause an extra burden on maintainers while not
helping to have smoother releases. So I'd rather have the best of both
than both under expectations.
> 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.
I'm not against having a constant useable testing, on the contrary. I
just don't see why we want to choose for working around the problems we
currently have with testing instead of fixing them for everyone.
Cheers
Luk
Reply to: