Hey Dan. I see that you read what I wrote and intrepid it in the worst possible way. I will try to be more clear and more carefully chose my words in the future.
I called it an “obvious mistake” because it was clear to me that we missed something. We are not bad people or worse developers because we made a mistake. We (the community) are also not shielded from making mistakes just because we have a voting process. I understand that other people are not consider it to be a mistake. That is fine. I am wrong to call it “obvious”. >> 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. I think there are over 1000 people with “voting powers”. I assume you trust a majority of them to have this “deep enough understanding of PHP core”. 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. > 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. 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. // Tobias > On 27 Aug 2021, at 10:44, Dan Ackroyd <dan...@basereality.com> wrote: > > 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
