"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > jean-frederic clere wrote: >> 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. >> > > so to me this is spanking clear, that the process is vague, and before > anything like this is implemented, it should be as black and white as RTC > and CTR if it's gonna work > at this point, the vote doesn't make sense, as it is obvious folks aren't > clear on the process being voted on. >
And, yet again, Filip chooses to question the validity of the vote, instead of discussing ideas :(. Now I feel insulted as well, since I'm fully aware on the process being voted on. But if I lived with Jon in the same community, I can live with Filip ;-). Remy was being really nice to the community by not requiring a vetoed patch to be withdrawn. Personally, I would go with j-f-c's position, and withdraw a vetoed patch immediately (and have done so on several occations, even when I got to re-apply it after enough discussion took place on the list). However, I'll go with whatever the community consensus is on this point. > Filip >> 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] >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
