|Deletions are marked like this.||Additions are marked like this.|
|Line 18:||Line 18:|
I would advocate a policy requirement that at least two ["DDs"] must be willing to maintain a package before it is accepted into the archive. And if there are not at least two developers interested in the package, it should be removed from the archive (to be enforced at a certain point in the future). Sponsoring a package counts as a form of co-maintainership also during the NM process.
Last time I saw it quoted, there were almost one thousand maintainers in Debian. If the group of developers for a package is not able to check up on a package (follow up in the BTS, etc) for a few weeks or months (set your favorite acceptable period of time), another co-maintainer should be requested for those packages.
A developer shouldn't have to worry about their packages while they are away at a conference, trip or vacation. I expect that this will allow little excuse for RC bugs, objections about ["NMUs"] and etc since there is already a group of maintainers per package that should be able to handle those issues quickly. If not, a RFM (Request for Maintainer) should be sent out to request someone with the required skills and interest.
I suspect that once the doors are open to mass co-maintainership, the need for ["RFMs"] will be infrequent. --MikeFedyk
Since the RC bugs are a critical issue, every developer should make sure his/her packages are as neat as possible. perhaps we are too lame and don't give our packages the love they deserve? if so, what can we do about it? more co-maintenance? more checks? harder policy?
Note: I am probably the lamest of all and this isn't meant to insult anyone
Watch files could be used more often to simplify the tracking and packaging of latest versions of upstream programs.
-- true, but that's not an issue for release-quality (at least not very much) -- robert
A related issue:
When the release drags on so long, new upstream releases are made and developers want to package these so they can use them. e.g. gnome 2.6, gnome 2.8... There are two options: 1) break sid, delay the release; 2) use experimental. Experimental is a pain. There are no autobuilders and it often has experimental packages in it which are broken. Users might want the latest gnome, but not at the risk of breaking other packages. Having separate, autobuilt experimental repositories (experimental-gnome, experimental-utopia, experimental-gcc...) would fix these problems. Note that gnome does work well in experimental -- proving that the concept is good; the problem is that the gnome team have done a lot of work to make this work - average developers don't have the time to do this for their own smaller packages/groups of packages.
Back to ReleaseProposals