Hi! > Indeed we started with the easy ones... there isn't any reason simple > patches > won't get merged very quickly.
There's a very simple reason - there are not enough people with enough knowledge about PHP internals to properly evaluate patches that do it on regular basis. Even the simplest patch takes time, at least if you do it the right way - you have to read it, understand if it's right, pull it, build with it, run tests with it if it has tests, merge it to multiple branches, etc. - this takes time. Time is a scarce resource. > > We have some PR which the disscussion about them is stuck, the question is > who > and when do we cut it off and send the author to rework his patch. After Why we need to "cut off" anything? I mean, if the case is obvious - like the author does not answer the feedback for many months - we could close it - but if the patch is being worked on, why should we remove it from public view? Some things go fast, some things take time. I think we need to go case by case. > Also, we have more than a few PR which the patch is OK, but are stuck due > to a > missing test. This is fair enough, but should also have some rule of thumb > for > these cases. Again, it would not be hard to add tests for many of them, the problem is again - time. For myself, I'd rather spend time on merging properly done patches or fixing bugs than finishing up patches that the original author could finish up. But if some people decide that this is a good way for them to contribute - that'd be great. Otherwise, removing these pulls from public view would only mean they'd never get taken care at all. > Seeing a long list of PR waiting for a year isn't much encouraging, I would > prefer to see people quickly either have their changes accepted, sent to > improve > the PR or completly rejected. Don't forget the PR can always be resent and > the > work isn't lost. The work isn't lost but once PR is closed the chance anybody would look at it again except original author is very low. While if it's open, it still could be a chance somebody would pick it up. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
