Tobias wrote: > I know you are not a bad person... > > The fact that you unprompted (as far as I can tell) decided to in > detail specify how RMs should make their decision about an RFC is > giving me a strong signal that you don’t trust the role of the Release > Manager. The timing of your RFC is also unfortunate assuming you don’t > want to imply they are doing a poor job as they just got some criticism > in a different thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really > hope you worked with a few of them while you drafted this RFC.
If you're going to call people names, you may as well do it openly, rather than through passive aggressive phrasing like this. Also, if you could stop describing decisions that you disagree with as "obvious mistakes" when the RFC author was pretty clear about the intention, and the vote passed 30 - 3. Quite a few times you're giving the impression that you think other people are dumb if they can't even see this "obvious mistake". > And to state something I hope is obvious: I am not accusing you for trying to > reduce the role of Release Manager or anything else. You are projecting here. You're the person who is proposing giving Release Managers new powers to have special RFCs where "vote should not consider “if it is too late” or “this is rushed”." > To allow the release managers to have this decision power is not a > “violation of voter rights”, that is just a silly argument. It's a change from what we've had before, and blowing off other people's concerns about putting too much power in the hands of a few people is condescending. > 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. Coincidentally, it is explicitly listed that the Release Manager role does not include deciding what gets shipped - https://wiki.php.net/rfc/releaseprocess#rms_role "RMs Role - But they are not: Decide which features, extension or SAPI get in a release or not" Nicolas Grekas wrote: > Can you please let me know how that helps? It helps point out how obtuse you are being. Yeah, everyone gets it, there are quite a few people who commit to Symfony who don't like that the "Pure intersection types" RFC only implemented a pure intersection type and didn't allow a union type with null. But having people from that community turn up, call people names, call things "obvious mistakes" and try to change what feature freeze means e.g. > but what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > anything that is not yet released should be re-discussable until either > beta or RC stage. 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, but I'm also pretty sure they expected you to behave better and not to throw mud around what processes the PHP does or should follow. If you want people who contribute to PHP core to ship 'more complete' features, how about getting Symfony the company (or any other company) to sponsor some of them: https://phpopendocs.com/sponsoring/internals cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
