On Aug 19, 2012, at 21:25, Ryan Stonecipher wrote: > On Sun, Aug 19, 2012 at 3:01 PM, Lawrence Velázquez wrote: >> On Aug 19, 2012, at 2:04 p.m., Ryan Stonecipher wrote: >> >>> When a port has a single maintainer, when is it acceptable to commit a >>> quick/obvious change to fix a bug? >> >> http://guide.macports.org/#project.update-policies > > Lawrence, > The only part of the guide which could be used as an excuse for > committing that change would be "A critical port is broken that > affects many users". > > Of the ports listed by running 'port echo depends:webkit-gtk' the only > big deal I could see was gimp2. > The only users who would have been left in limbo would be those > installing webkit-gtk dependents for the first time after r96828. > Ticket #35737 could have sat for longer than 19 hours while the > maintainer, who chose to take exclusive control of webkit-gtk, may > have been able to begin researching (or letting users submit) an > appropriate solution. > > The fix which was committed well before the 72 hour maintainer timeout > period seems to have been the wrong solution for the problem. > Perhaps a patch could be added to the ticket and a request sent to > macports-dev and/or portmgr for permission before jumping to the > conclusion that "A critical port is broken that affects many users."
In this case I think there are a number of extenuating circumstances: * The maintainer Dave has not committed to this port in 22 months, indicating a likelihood that he may no longer be interested in it. * There are dozens of open tickets about Dave's various ports that he has not acted upon. He emailed me privately a month or two ago to indicate he was somewhat busy with non-MacPorts activities and thanked me for solving some of his other tickets. * This mesa dependency may have been a new requirement in webkit-gtk 1.8.x, which would make this a follow-up commit to the one that updated the port to 1.8.2 in the first place, which resolved a 9-month-old ticket and was thus already under the maintainer timeout regulation. If you're going to update someone else's port, and the update breaks things, then I feel that you certainly should do follow-up commits to fix the things you broke, and not leave the maintainer to fix problems they didn't cause. I myself have also been occasionally committing simple and obvious fixes for ports that are not openmaintainer. For example, to indicate what the project's license is, when it's unambiguous what it is. Or the rather common sed locale complaint on Mountain Lion: We know the problem, we know the solution (add "-locale C" to the reinplace invocation), the maintainer wouldn't have any justification for declining the fix, and the maintainer might not have access to Mountain Lion to have encountered the problem or to test fixes himself. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
