Tobias Nyholm wrote on 8/27/21 13:11: >>> one way of reading this proposal is that we don’t trust the release >>> managers to decide what to include and not to include in a release. >> >> To be clear, I don't trust release managers to decide that. Though >> they are all lovely people, not all of them have a deep enough >> understanding of PHP core to be fully able to evaluate changes. > > If you don’t trust the release managers to manage the release, then I suggest > you should improve the way we select new release managers.
I'm not speaking for Dan here, but as one of the release managers, I don't think Dan's statement was intended to mean he doesn't trust the release managers to "manage the release." What he said is that he doesn't trust the release managers to decided what to include and not include in a release. A PHP release manager's job is narrowly defined as: > A release manager's role includes making packaged source code > from the canonical repository available according to their release > schedule.[1] That's pretty much it. That's our job. Our job is NOT to decide what goes into a release. That's the job of the voters. That said, the release schedule (which is completely within the purview of the release managers' jobs) defines dates for each release, including the feature freeze, and the release managers have the authority to change these dates, if necessary. We did not choose the change the dates in this circumstance because there was no need to change them. There were no issues requiring a change to the release schedule. >> One of the hardest things to do in an Open Source project is to say >> 'no' to someone when they are making a request that isn't completely >> unreasonable. IMO, it would have been better if the 8.1 RM managers >> had said no to opening the "Nullable Intersection types" RFC, > > Yes, but it does not mean that you *have to* say no. > But I do agree with you. The process would have been way better if they said > “no". Or if they clearly and unanimously said “yes” which would remove focus > on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. We already have this power, and we exercised this power in this particular situation, but we are also human, and we made some communication mistakes. > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. To be clear, we DO NOT have the power to veto an RFC, and this is not a power the release managers should ever have. Cheers, Ben [1]: https://github.com/php/php-src/blob/master/docs/release-process.md
signature.asc
Description: OpenPGP digital signature
