On Mon, Mar 21, 2016 at 8:45 AM, Branko Čibej <br...@apache.org> wrote:
> On 05.03.2016 04:43, Konstantin Boudnik wrote: > > It saddens me to see this coming to it ;( > > Yeah. You guys are introducing red tape that's a barrier for new > committers and a bureaucratic trap for everyone else. > > For example: what happens when a module owner takes off for a couple > months? Which is likely, since this is, after all, a volunteer effort. > Are you going to block any changes to that module until/unless she > becomes active again, or just break your own rules for convenience? > Most modules have 2 or 3 owners, responsible for reviewing changes. If delayed reviews become an issue, which I doubt, we can always reassign or add ownership. > Maybe you're counting on many module owners being employed to do this > stuff ... in which case you should all go back to the incubator because > you've learned NOTHING about open source collaboration in all this time. > Pah, what nonsense. > I think everyone is entitled to their own opinion. I personally had no preference here and did not get involved in this community discussion. However, it is clear that the community prefers this process, after giving CTR an honest try, so let’s be respectful of the outcome. > > -- Brane > > P.S.: Also please stop using "Ignite is complex" as an argument for > locking down on progress. Give the other guy the courtesy of assuming > he's not a total idiot. How about spending time on a comprehensive test > suite and developer documentation instead? > > > > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > >> Igniters, > >> > >> I would propose to switch back to review-then-commit process. This > >> process has to be followed by both contributors and committers. > >> > >> There is a reason for this I have in mind. Ignite is a complex > >> platform with several big modules. Some of the people may be experts > >> in module A while others in module B etc. > >> If a committer, who is good in module A, makes changes in module B > >> merging the changes without a review this can break module's B > >> internal functionality that the committer didn't take into account. > >> > >> My proposal is to introduce a list of maintainers for every Ignite > >> module like it's done in Spark [1] and a rule that will require a > >> committer to get an approval from a module maintainer before merging > >> changes. > >> > >> Thoughts? > >> > >> -- > >> Denis > >> > >> [1] > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > >> > >> > >> > >
