Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit : > > Releasing is regularly the hardest thing that Debian does, not just > technically but also socially. Apart from the standard issues of setting > deadlines, RC bug counts being high, and similar difficult technical > issues, the process seems to eat volunteers.
Dear Russ and everybody, I think that our release process is manpower-hungry by design, and that the more packages and architectures we have, the harder the release is. I propose to refocus our efforts. Solving a thousand of RC bugs is a herculean task for a small group of persons. But why should they do that in the first place? Most of these bugs are the responsibility of the package maintainers. If they can not make their package ready for the release, will they be able to help for stable support? Who will do that work? I propose that we reshape the sections and priorities of our archive, so that it is easy to remove from Testing any RC bug that is not in a core pakcage, and is old and not tagged RFH. In parallel, I propose that the definition of what the ‘core’ is can vary between architectures. The goal is not only to reduce the workload of the release team and the porters. It is also to give some meaning to the presence of a package in a stable release. These packages must be there because there is agreement that enough users are insterested in it, and are comfortable with the idea to keep it at the same version for a long time. For many peripheral leafs and branches of our dependancy tree, let's innovate and distribute them through other channels, like official backports and even the new snapshot system that is being set up. When all of this is aptable from the official Debian mirrors, it will open great opportunities to build tailored Debian systems, for instance with the ‘blends’ framework. Debian is volunteer-driven, so the release can only happen by coordination. Acutally, it is a coordination process by nature: a release is a moment in the development where all the core components work well together. If these components evolve independantly, it will hardly happen by chance. Motivation must be there on both ends. This is why I propose to limit the release to the packages where there is a real motivation for it. When maintainers feel the need for a release, they will have to talk to the others and eventually make concessions on their timeline. Not to mention that for many of our packages, there is actualy nobody who regularly cares for them anymore. In that sense, I think that membership issues are one of the roots of our difficulties to release. As a DPL I will help the Project to evolve its release and membership process through my constitutional roles: leadership in discussions, GRs, and delegations. I expect as a result that the release work will become much more social than technical, with all participants doing their part of the housekeeping work. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317005207.ga6...@kunpuu.plessy.org
