Branko,
Personally, it's not clear to me why the decision on having RTC process
for committers for most critical modules shows our immaturity in a sense
of open source collaboration.
As Raul properly noted below, the committers were always using RTC
informally for most of the modules trying to reach each other asking to
check changes before they get merged. In my understanding it shows that
Ignite committers takes care more on the quality of the contributions
rather than on a number of patches that get merged in a day or in a
week. The only thing we did for now is that we put this type of
collaboration on a paper.
It's not feasible to create a super comprehensive test that will check
all the cases, it's not realistic to document every line of the internal
code. But it's always possible to check your contribution with a
committer who is more experienced in a specific functionality, get his
feedback and as a result grow your own expertise.
In my initial example I referred to Spark community that has a list of
maintainers as well. I think that this rule didn't lead to the project
stagnation but rather allowed to adopt Spark in tons of projects
worldwide by delivering releases with high quality. At this moment
Ignite community decided to go this way as well. We're free to change
our decision later if something doesn't work.
--
Denis
On 3/21/2016 6:45 PM, Branko Čibej 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?
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.
-- 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
