I'd like to propose a policy for dealing with issues where users or packagers find a possibly trivial bug in a package, decide to fix it, and end up seeing their patch ignored and rot away. This can be frustrating for packagers because the bug may be blocking their own packages, and also for users, since they feel that their contributions are not welcome and might get discouraged from future attempts.
Currently, the options to deal with such situations are: - chase the package maintainer and hope for a reply: if the package maintainer is either absent or too busy to care, this is often unsuccessful. - start the non-responsive maintainer process: for packagers, it will be at least four weeks before they can take over the package and apply the fix. For non-packagers, this is not an option. - request the help of a proven packager, either via irc or on -devel: it is not always easy to get the attention of a proven packager, for normal users, it can be even harder.
I've started a corresponding thread on -devel [1], and since overall the response seems to have been favorable, at least to the point where people agree that such situations pose a problem, I put together a more formal proposal [2]. Essentially, it consists in giving users the possibility to file a "simple patch request" in a well-defined way which causes the smallest amount of work to proven packagers, and gives users/packagers a clear set of steps for dealing with such situations.
The discussion on -devel has mostly died down, I'd now like to formally submit the proposal to FESCo for further discussion. Goes without saying that I'm clearly happy to help with such simple patch requests should a proposal along these lines get accepted.
AFAICS this is simply a more formal version of the “request the help of a proven packager” case, and as such obviously non-objectionable. (There’s of course no guarantee that there will be available and willing provenpackagers to apply these patches.)
It would be useful to have (but not a blocker for this proposal) a script/tool to apply the “simple patch request” by a provenpackager, to minimize manual automatable work,
Right, the reason I'd like to see the "Simple patch requests" formatted similarly to the "New package requests" is that it would make them easy to parse by a script, hence all the proven packager would need to do is review the patch and fire the script.
Adding meeting keyword
In my opinion FTBFS issues should be handled carefully, and possibly be even mandated to be fixed by package maintainers or their explicit ack and nobody else unless it is known that the packages in question are being properly maintained.
If a package is FTBFS for multiple releases, it gets rightfully retired or flagged for retirement and thus subject to call for new maintainers because it has not been really maintained for a long time.
If a drive-by contributor goes and fixes a trivial FTBFS issue in a practically unmaintained package, it won't become subject to the above process and may be left in the distro in zombie state for longer than it should.
policy is approved (+6,0,0)
Login to comment on this ticket.