r96828 [webkit-gtk: Add mesa dependency (#35737)]

[Joshua Root]

Maintainership was certainly never meant to stop other people from
fixing bugs. We should probably add "the port fails to build at all on a
currently supported platform" to the list of acceptable reasons, since
it's hard to make things worse in that case (provided you take simple
precautions like restricting changes to the platform(s) where they're
known to work).

The flip side is that if you're not certain the fix is correct, you
probably shouldn't commit it. And changes that are risky or disruptive
are another good reason to wait for the maintainer to review.

- Josh

On 2012-8-20 12:25 , Ryan Stonecipher wrote:
> 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."
> 
> Ryan Stonecipher
> 
> 
> On Sun, Aug 19, 2012 at 3:01 PM, Lawrence Velázquez
> <larry.velazquez at gmail.com> 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
>>
>> vq