Hey, On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes <l...@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, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik81b7l5l8bbivub=5sopzw8-fcm3zhxlygw...@mail.gmail.com