Let's forward this to the right address. ----- Forwarded message from Petter Reinholdtsen <[EMAIL PROTECTED]> -----
From: Petter Reinholdtsen <[EMAIL PROTECTED]> Subject: [Debconf4] Some notes on package removal and archive quality Date: Mon, 31 May 2004 21:37:07 -0300 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: We discusses several topics during the BOF about package removal. Here are some notes I managed to take during the discussion. It would be nice if we could come up with and document a set of indicators that can be used to detect packages that should be removed from the archive. Could we use popularity contest installation count as an indicator? If no-one has a package installed, perhaps it should be removed. Some liked the idea, while others warned that the quality of popcon might go down if the results where used to select which packages were kept in the archive, as it is very easy to fool popcon if one want to do so. It might be an idea to use this info to let the maintainers know how much the packages they maintaine are used, to let them consider if the package is worth maintaining in debian or not. Should it be simpler to throw packages or, or should it be harder to get in? Keeping it easy to get it give the packages a chance to improve, while making it harder to get in will improve the quality of the packages. Throwing out packages are hard, as there need to be a method to warn users and machine admins that a package they are using are removed from debian. It might be an idea to add some quality check before allowing packages to enter testing for the first time. The security team should possibly have a say as they are expected to do security patching on the packages when testing becomes stable. Some ideas for a quality check for unstable -> testing: - security audid - suid? - tmpchecker? - more? - QA tests - is there an upstream - no lintian warnings/errors - more? - available translations in program and debconf templates? We should do automatic upgrade testing, to make sure packages actually upgrade as they should. Petter has a script for doing this at <URL:http://developer.skolelinux.no/~pere/upgrade-testing/>, but it would need more work before it can run unsupervised on all the packages in the archive. A good indicator is if there is more than a year since the last upload of a package in main, and it haven't been able to enter testing yet. This can indicate no active development, and a maintainer not working actively to get the package ready for inclusion into testing. Perhaps we should start by checking large packages, to try to reduce the archive size? We should try to find unused libary package and remove then (remember to check all architectures). Something like deborphan on the archive would be nice. We discussed which criterias should be used to remove an arch. The general consensus was that a package should be allowed to stay as long as there were enough people working on maintaining the arch. Martin said that he had been discussion criterias for adding an arch with a ftp-master, and some bare minimum criteria would be that it had more then 90% of the packages built, and a working debian-installer. Packages should probably be removed if they fail to fullfill the criteria for being added for a long time (6 months?). We touched on the topic of finding inactive developers. It might be an idea to send an email once a year if no uploads/bts messages/other emails have been registered from that developers for a year. This way we can make sure at least the forwarding mail address is working, and detect missing maintainers sooner. There were questions on how we detect developers that disappear or die, and there seem to be no safe way to do it at the moment. It might be a good idea to add an emergency phone number to the developer database. We touched some other topics as well, but I didn't manage to take notes fast enough to record them. :) This bof summary is ment as input to the QA team and any others interested in improving the quality of the packages in the debian archive. _______________________________________________ Debconf4 mailing list [EMAIL PROTECTED] http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/debconf4 ----- End forwarded message ----- -- Martin Michlmayr [EMAIL PROTECTED]
