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. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100926184008.gi22...@rivendell.home.ouaza.com
