Kevin Mark <[EMAIL PROTECTED]> writes: > Just a thought. How about setting up an aging system for who can fix the > bugs. Give the maintainer N time period to act on the bug and then if > the maintainer can not fix it or will not fix it, other folks who have a > patch should be able to apply to fix it.
We already have this, and the time N is zero days. That is, as soon as a bug has been filed you can freely figure out the fix yourself and submit a patch to the BTS. (This is the subtext to my comments here: instead of complaining about maintainers not fixing bugs, go fix some. It isn't the maintainer's job to fix every bug, and if you want to fix bugs--a very good thing to want to do--go fix em!) > if the maintainer feels that the patch should not be applyed, there > should some authority to hear the pros and cons of the issue and > arbitrate the result--would that be the tech commity, app. manag., > RM or ? We already have this, it's the tech-ctte which is there to mediate technical disputes that developers cannot settle themselves. > It seems that folks go MIA for legitimate reasons but the > package suffers. Yes, and debian-qa already has procedures in place for dealing with MIA developers; either completely MIA, or developers who are not maintaining a package at all while still doing other work. What the present thread seemed to be about was maintainers who *are* maintaining a package, doing uploads for it and so forth, but who are not fixing very old bugs in the package. > it seems like allowing someone to come in to fix a > package or takeover a packages has to deal with the ego of the > maintainer. Not really; if the point is a fix, post a patch to the BTS. If you want to take over a package where the developer really has not been uploading it, post a query to debian-qa. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
