## Auto-converted by kwiki2moinmoin v2005-10-07 = Beware, this is an old proposal = This proposal is superseded with this one: CollaborativeMaintenance = Proposal to handle orphaned packages = Following [[http://lists.debian.org/debian-qa/2005/07/msg00035.html|the mail]] that Raphaël Hertzog published on the debian-qa mailing list, a proposal for a better handling of orphaned packages arised. This document will sumup the ideas behind all the thread, in order to clarify what we can do to better handle orphaned packages. == What is wrong with Debian orphaned packages? == Nothing but since we're about QA, we want to do always better. The main problem with orphaned packages is that we don't find a new Debian maintainer. But in some cases, we have volunteers outside of Debian willing to maintain the package... but those volunteers can't afford to spend the time needed to become an official Debian maintainer. The package already exists and thus the packaging effort is minimal. The new maintainer process is a barrier for those contributors. This proposal aims to create an infrastructure so that external contributors can maintain some packages with the help of some members of the QA team. At the same time, we can use this new infrastructure to maintain all orphaned packages in a more centralized manner. We want to setup a system that would allow external developers to patch our orphaned's source packages and let the Debian QA Team overlook the resulting package, and upload it if needed. This not an adoption, but rather a collaborative work between external developers (who focus on the code of the software) and the QA Team who, as usal, focuses on enhancing the quality of orphaned packages. We want to make all this process as smooth as possible. == How would it look like? == === The Debian QA SVN repository === All the orphaned packages would be (automatically) integrated in a subversion respository so that all packages can be handled with svn-buildpackage. The SVN repository is hosted on svn.debian.org and access is controlled via the {alioth:collab-maint}. The repository would contain 3 directories: * orphaned: orphaned packages maintained by Debian-QA * ext-maint: oprhaned packages maintained by external contributors * deb-maint: orphaned packages which have been adopted by a DD (and who decided to continue to use this repository to maintain the package) The orphaned directory will basically host every orphaned packages (the import should be done automatically whenever the package is orphaned by an upload to the archive). The ext-maint (externally maintained) branch will host every packages for which an external developer waved and proposed his help. Those contributors would be listed somewhere so that we can "ping" them when needed. Of course, when the status of a package changes, we can easily move the sources from one directory to another one. The move from the orphaned branch to the ext-maint one should be manually performed, by a Debian member of the QA Team. This will allow us to easily see which packages are totally orphaned (no one cares, even outside Debian) and which ones are not. ==== Remarks concerning the SVN repository ==== We could use ACL possibilities to give automatic read/write access to all Debian developers. We can also write some subversion hook scripts: * to limit access of external contributors to the package they registered for * to send automatically "diffs" to the PTS (keyword: cvs-commit) For a smooth transition to subversion, the system could automatically detect upload of orphaned packages generated from another source (and mail the uploader and import his changes). This is possible because svn-buildpackage should create a tag for each version built and uploaded. === Website === Along with this repository we need a webpage listing the orphaned packages and their status : * do we have external contributor for a package ? (names and emails) * upstream URL (=> where we can look to find potential external contributors) * do we have changes in the SVN repository since the last upload to Debian ? (would provide a link to a diff which has been automatically generated) * is an upload requested ? (ex: when changelog mentions "unstable" instead of the usual "UNRELEASED") * link to the PTS of the package * big red warning if quick attention is needed (RC bug for example) [[http://adn.diwi.org/wiki/index.php/QA-Orphaned|A first draft]] of such a page has been written. == Expected benefits == * Avoid removing packages without a Debian maintainer if we have external contributors/developers willing to help. * Attract new contributors to Debian because they can concretely help without doing NM * Reduce the workload of Debian-QA, because they don't have to handle all oprhaned packages. They can simply check the changes done by other and build/upload the packages. * Simplify the coordination of the work of maintaining orphaned packages. One is not forced to make an upload after a little change, because that change won't be lost if someone else comes and work on the package a few days later. As a side note, this system (or a copy of it) can also be used by people in the New Maintainer process to handle their packages... this would help the sponsor to review the changes. == External Contributors == External contributors/developers are people who use an orphaned package, know how to patch it, and are ready to help Debian to ensure that the package stays in a good shape. On the other hand, those people just don't want to enter the long NM process or go through the harrasment of finding a sponsor to adopt the package, they just want to give support for the sources, to help the QA Team. We find sad that orphaned packages might have several patches in the BTS lying for years. This proposal aims at minimizing the work of the QA Team, and thus, maximizing the upload of orphaned packages. Those external developers should be added in the alioth qa project when they want to provide patches for an orphaned package. They can then commit all the patches they want and ask a Debian member of the QA team to review and upload the package when needed. == What should be done == Everything. We have an empty SVN repository, that's all. * Write script to automatically import orphaned packages in the repository. This script can be called daily to import new orphaned packages and eventually to integrate a new version which didn't originate from the subversion repository. * Write scripts and tools to generate the webpage. * Create helper tools to ease the work of the Debian-QA members (download latest sources, generate a diff against the last version in unstable, ...) * Document everything. When everything is ready, we should communicate a lot about that, so that people know that external developers are needed for these packages. A first interesting work might be to contact upstream for each orphaned package (if it exists), and ask if someone wants to become an external developer for Debian.