Remy Maucherat wrote: > jean-frederic clere wrote: >> Filip Hanik - Dev Lists wrote: >>> Remy Maucherat wrote: >>>> Hi, >>>> >>>> Another more precise draft. >>>> >>>> Patches which would go to review would be: >>>> - API changing patches (any protected or above signature change) on >>>> APIs which are accessible to the user either from confirguration or >>>> programmatically >>> yes, makes sense >>>> - any other commit for which a committer asks for the RTC procedure >>>> should be rollbacked if it hinders concurrent work or is to be >>>> included in a release tag, and go through the RTC procedure >>> -1. There is a huge risk for "I simply don't like it, revert it". >>> Anything that is to be rolled back, should be backed up by a technical >>> reason. So in this case, how do you define "it hinders concurrent work". >>> Either we do RTC or we don't, but having a vague definition in between, >>> doesn't make sense. >> >> That is not: "I simply don't like it, revert it" that is "I think it >> needs review, revert it and let's discuss it". >> I would proposed that the one that does the -1 should come with another >> fix in few days for a fix for a PR, another proposal for API/conf >> changes and participate to the discussion on the -1 otherwise the -1 >> would become is invalid. > > The patch does not need to be reverted when under review, except if > there's a need to tag a release or something similar.
Well I see at least 3 reasons to revert it: - Prevent accidental inclusion in a release. - Allow a more easy testing and evaluation of a another patch that fixes the same thing. - Force the community to look for another solution. Cheers Jean-Frederic > In that case, > including such a patch would not be acceptable. The other case is if it > causes development issues, but it should be extremely rare (as API > changing patches would get reviewed before being committed). > > I also don't think any reason needs to be given for voting against a > particular patch under review. If only one committer votes "no", then > you need one additional "yes" (4 total), which sounds achievable. If two > committers vote "no" (most likely you would be in a veto situation at > the moment) then it's still doable if everybody else wants it. With 3 > against, the community is basically split, and it seems impossible to > follow through without changes to convince the other camp. > > The general idea is to be able to disagree with something without using > something absolute like the veto mechanism, since the only thing that is > going to be examined (at least at the moment) seems to be its validity. > Also, if a vote is tied to a justification, then any discussions will > immediately switch over from technical to "let's show the justification > is not valid, so that we can ignore it" mode. > > If it turns this new mechanism does not work, then I think new proposals > can be made to change it quite easily. > > Rémy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
