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 RTC procedure would include a STATUS file in the Tomcat svn >> listing all pending "up to review" changes. A successful vote with a >> +3 margin is required. A patch can remain under review for as long as >> the committer wishes, and it should be allowed to freely "advertise" >> and discuss the vote. >> >> The idea would be to force a consensus for commits which could have >> significant implications, and help stage technical discussions (rather >> than discussions about the validity of the disagreement). It would >> introduce a small delay for committing certain patches and a minor >> slowdown for development pace in theory, but in practice I've noticed >> conflicts waste a lot more time. > The community has always been open to technical discussions, it's the > countless vetoes without technical justifications that became the major > pain in the rear. The problem is more the time that is spend to discuss the validity of -1 is lost time for me. It seems a reaction to a veto of a commit in the TC community is somehow wrong... The correct way should be "thank you for reviewing my commit, I will rollback and let's discuss a better solution" and not what happens those days. >> >> This would also mean it is possible to make a change that a number of >> committers oppose (possibly, would veto) if enough committers are in >> favor of it. > I don't really see the need of doing our own version of a semi RTC, > either we do RTC on release branches and CTR on trunk. > So I'd be -1 on this, the main reason, is that the definitions are not > common nor defined within the larger ASF community, hence the vagueness > would only arise for more debates. What Remy proposed is a RTC on demand I think we should try it and improve it while using it. Cheers Jean-Frederic > > Filip >> >> 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]
