On Sat, 27 Dec 2008 02:04:29 +0100 Patrick Matthäi <patrick.matthaei@web.de> wrote: > Jonathan Wiltshire schrieb: > > On Fri, Dec 26, 2008 at 10:37:37PM +0000, Neil Williams wrote: > >>> What if not? They stay open till someone else > >>> tries to package it and gets rejected? > >> If there is no good reason to turn an RFP into an ITP and thence into > >> an upload, there is no reason to leave the RFP open. > > > > I think perhaps the question was as much 'who should check the list and > > close useless ones', and whilst there isn't neccessarily anyone who > > _should_ be doing it, there's no reason prospective developers _can't_ > > do it. Just make sure you annotate your closure with some reasoning, so > > that the requestor doesn't just re-open the RFP. > > We have many packages which are providing the same functionality. So there is no reason to add more and the ones that do exist are reviewed intermittently, usually around the time of a release or if the maintainers change. > I think in *most* cases the requestor has a reason for his RFP, for > example he is using itself and find it usefull, there may be more reasons. That is not a good enough reason to have the package in Debian. I could write mylibc6 and change one line - it would be the version I use myself, I'd find it useful but nobody should allow that needless duplication into Debian, let alone the effects on other packages. Those who are interested in the package make the choice - for whatever reason. If you are sufficiently interested to look at an RFP *you* need to make the assessment about whether the RFP is justified - as with any bug. The first step in bug triage is: is this a real bug? is it justified? is it worth doing anything about or is the submitter just confused? RFP and WNPP are not dumb queues. > I think packages should not be rejected just because they provide > "duplicated" functions. I think all packages must be rejected if all they provide is duplication. One stage on from that is the security team requirement to avoid code duplication and embedded copies of the same code. Duplication is harmful. There should be one place to fix one bug, not dozens. The alternatives system provides the support for similar functionality in different implementations and a choice of editors, web browsers and email clients is a good thing. However, there is a line to be drawn and wholesale duplication crosses that line. > But yeah, who realy decides which RFP requests are realy sensless and > should be closed? Whoever is sufficiently interested to read the RFP in the first place. If that fails, as here, then the ITP gets CC'd to debian-devel where there is a chance of feedback on unnecessary duplication and if a sponsor is required, there is yet another chance for someone to see sense. Failing that, ftp-master can simply reject it and if it gets added by mistake, it can be removed. Why waste time on something that is just going to be killed off anyway? > Anyway we are here off topic, this should be discussed on another list, > thanks. RFP management and bug management in general is very much on-topic for this list and should be discussed more readily - particularly with relation to orphaned bugs, if only to encourage maintainers not to package yet another duplicate of something that is already well maintained. O bugs again need review - it was orphaned for a reason, is that reason anything to do with the package or a dead upstream? If not, does the orphaned package have any role in current Debian? Again, if there is any package that is close enough to the orphaned package that it can do the job then the role must be passed to the package that has the most active maintenance and the O bug has to be made into an removal (RM) bug. It is better to submit a few wishlist bugs against the nearest alternative than to adopt an orphaned package that is 95% identical to something that already exists in the archive. Sometimes old software (I'm looking at you xmms) just needs to DIE! Debian is not a dumping ground for abandonware and bloat. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgphIP6lOHa9c.pgp
Description: PGP signature