Jira Process

[Konstantin Boudnik-2]

On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <[hidden email]> wrote:

>On 27.07.2015 09:43, Atri Sharma wrote:
>> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <[hidden email]>
>wrote:
>>
>>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
>>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]>
>wrote:
>>>>> We've all seen problems with bad commits. Bugs happen. If it's
>>>>> accidental, live with it. If it's consistent from some person,
>teach
>>>>> said person to do better. There's no reason to go all paranoid
>over a
>>>>> potential occasional bug in a commit.
>>>>>
>>>>> I mean, it's ridiculous to go all agile with sprints and scrums
>and CI
>>>>> and whatnot, and then block progress because you're afraid to
>trust your
>>>>> fellow developers to not goof off all the time.
>>>>>
>>>> Just as an observation, I don't think RTC process was slowing down
>>> progress
>>>> at Ignite as reviews usually happen pretty fast.
>>> They do now, when the project is fresh and the majority of active
>>> committers are actually not doing this in their spare time. You need
>to
>>> think ahead a bit, too.
>>>
>>>
>> I do see your point but I think you will agree that a pre message on
>> developers list is necessary giving time for  potential objections.
>
>The point is that I definitely do not agree with that. Developer
>receive
>commit notifications; that's enough of a nudge to review the commit.
>
>In my experience, prior reviews don't find any more bugs that post
>reviews. This assumes two preconditions: a) Design discussions and
>decisions are made on the dev@ list before a feature or change is made;
>and b) developers request a prior review when they feel it's necessary.
>But it should be up to the developer to make that judgement call.

Huge +1, really. It's truly in the spirit of trustworthy and healthy community.

[Sergi]

Guys,

I would say Ignite is quite a big and quite complex project. Also we have
really tough requirements for performance, stability, backward
compatibility, etc... Having said that it is really easy to break something
even with minor change like switching type of collection to another one.
And I personally feel safer when my code has been reviewed before I merge
it to master. Also when thousand lines change set is merged and there are
conflicting change sets merged after, it is quite hard to rollback this
first change if it was wrong. And we have conflicting changes all the time.
My opinion is that correct trade off for us now is having slower but more
predictable development. RTC approach here definitely fits better.

Sergi



2015-07-27 11:01 GMT+03:00 Konstantin Boudnik <[hidden email]>:

>
>
> On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <[hidden email]> wrote:
> >On 27.07.2015 09:43, Atri Sharma wrote:
> >> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <[hidden email]>
> >wrote:
> >>
> >>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> >>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]>
> >wrote:
> >>>>> We've all seen problems with bad commits. Bugs happen. If it's
> >>>>> accidental, live with it. If it's consistent from some person,
> >teach
> >>>>> said person to do better. There's no reason to go all paranoid
> >over a
> >>>>> potential occasional bug in a commit.
> >>>>>
> >>>>> I mean, it's ridiculous to go all agile with sprints and scrums
> >and CI
> >>>>> and whatnot, and then block progress because you're afraid to
> >trust your
> >>>>> fellow developers to not goof off all the time.
> >>>>>
> >>>> Just as an observation, I don't think RTC process was slowing down
> >>> progress
> >>>> at Ignite as reviews usually happen pretty fast.
> >>> They do now, when the project is fresh and the majority of active
> >>> committers are actually not doing this in their spare time. You need
> >to
> >>> think ahead a bit, too.
> >>>
> >>>
> >> I do see your point but I think you will agree that a pre message on
> >> developers list is necessary giving time for  potential objections.
> >
> >The point is that I definitely do not agree with that. Developer
> >receive
> >commit notifications; that's enough of a nudge to review the commit.
> >
> >In my experience, prior reviews don't find any more bugs that post
> >reviews. This assumes two preconditions: a) Design discussions and
> >decisions are made on the dev@ list before a feature or change is made;
> >and b) developers request a prior review when they feel it's necessary.
> >But it should be up to the developer to make that judgement call.
>
> Huge +1, really. It's truly in the spirit of trustworthy and healthy
> community.
>
>
>

[Konstantin Boudnik-2]

Wait, conflict resolution should be done at the dev. branch, not on master.
Also, if your work is properly rebased than rollback becomes a trivial

    git revert SHA1

In the current schema of things a rollback might be indeed hard, because
branch merges bring tons of commits like
    "Ugh, damn, I forgot to fix the type"
or
    "Merge master to my-dev branch"

which are non-informative junk that just pollutes the history and makes
navigation impossible.

Cos

On Mon, Jul 27, 2015 at 07:29PM, Sergi Vladykin wrote:

> Guys,
>
> I would say Ignite is quite a big and quite complex project. Also we have
> really tough requirements for performance, stability, backward
> compatibility, etc... Having said that it is really easy to break something
> even with minor change like switching type of collection to another one.
> And I personally feel safer when my code has been reviewed before I merge
> it to master. Also when thousand lines change set is merged and there are
> conflicting change sets merged after, it is quite hard to rollback this
> first change if it was wrong. And we have conflicting changes all the time.
> My opinion is that correct trade off for us now is having slower but more
> predictable development. RTC approach here definitely fits better.
>
> Sergi
>
>
>
> 2015-07-27 11:01 GMT+03:00 Konstantin Boudnik <[hidden email]>:
>
> >
> >
> > On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <[hidden email]> wrote:
> > >On 27.07.2015 09:43, Atri Sharma wrote:
> > >> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <[hidden email]>
> > >wrote:
> > >>
> > >>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> > >>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]>
> > >wrote:
> > >>>>> We've all seen problems with bad commits. Bugs happen. If it's
> > >>>>> accidental, live with it. If it's consistent from some person,
> > >teach
> > >>>>> said person to do better. There's no reason to go all paranoid
> > >over a
> > >>>>> potential occasional bug in a commit.
> > >>>>>
> > >>>>> I mean, it's ridiculous to go all agile with sprints and scrums
> > >and CI
> > >>>>> and whatnot, and then block progress because you're afraid to
> > >trust your
> > >>>>> fellow developers to not goof off all the time.
> > >>>>>
> > >>>> Just as an observation, I don't think RTC process was slowing down
> > >>> progress
> > >>>> at Ignite as reviews usually happen pretty fast.
> > >>> They do now, when the project is fresh and the majority of active
> > >>> committers are actually not doing this in their spare time. You need
> > >to
> > >>> think ahead a bit, too.
> > >>>
> > >>>
> > >> I do see your point but I think you will agree that a pre message on
> > >> developers list is necessary giving time for  potential objections.
> > >
> > >The point is that I definitely do not agree with that. Developer
> > >receive
> > >commit notifications; that's enough of a nudge to review the commit.
> > >
> > >In my experience, prior reviews don't find any more bugs that post
> > >reviews. This assumes two preconditions: a) Design discussions and
> > >decisions are made on the dev@ list before a feature or change is made;
> > >and b) developers request a prior review when they feel it's necessary.
> > >But it should be up to the developer to make that judgement call.
> >
> > Huge +1, really. It's truly in the spirit of trustworthy and healthy
> > community.
> >
> >
> >

[Branko Čibej]

On 27.07.2015 18:29, Sergi Vladykin wrote:
> Guys,
>
> I would say Ignite is quite a big and quite complex project.

This has absolutely nothing to do with trusting developers. FWIW,
Subversion is also very complex, I'll dare say that its object model and
working copy semantics are more convoluted than anything you'll find in
Ignite. We make do with CTR quite well.


>  Also we have
> really tough requirements for performance, stability, backward
> compatibility, etc...

Write them down. Make sure new contributors understand them before
offering them commit access. That's a prerequisite for growing an open
community anyway.

> Having said that it is really easy to break something
> even with minor change like switching type of collection to another one.

So? Stuff like that should be documented in the code, if it isn't no
amount of prior review will help, since how do you know that the
reviewer happens to remember such details a few years from now?

> And I personally feel safer when my code has been reviewed before I merge
> it to master.

So ask for a review if you think you need it. I never said *all* reviews
should be post-commit: I said that the default mode should be CTR and
it's up to the developer to ask for more eyes on their code.

> Also when thousand lines change set is merged and there are
> conflicting change sets merged after, it is quite hard to rollback this
> first change if it was wrong. And we have conflicting changes all the time.

Apparently you need to learn to use the version control tool you
selected, or adjust your workflows for the failings of said tool. Or
change the tool, who knows, you might find that's a good move. :)

Regardless of which tool you use, conflicts should *ALWAYS* be resolved
on the development branch, not on the mainline: the workflow should be:

 1. create branch from mainline
 2. make changes on branch
 3. merge mainline to branch and resolve conflicts (repeat as needed)
 4. run tests on branch code
 5. merge branch to mainline

Skipping step 3 (and 4) is going to be a constant pain regardless of
which tool you use. Also for trivial changes it makes no sense at all to
even create a branch; just fix it on the mainline, your version history
will be a lot easier to follow.

> My opinion is that correct trade off for us now is having slower but more
> predictable development. RTC approach here definitely fits better.

RTC has an additional problem that it can (and often does; look at one
of the most famous ASF projects if you don't believe me) create tensions
in the community. It makes sense to use it for maintenance branches, but
not for new development.

-- Brane

[Konstantin Boudnik-2]

On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:

> On 27.07.2015 18:29, Sergi Vladykin wrote:
> > Guys,
> >
> > I would say Ignite is quite a big and quite complex project.
>
> This has absolutely nothing to do with trusting developers. FWIW,
> Subversion is also very complex, I'll dare say that its object model and
> working copy semantics are more convoluted than anything you'll find in
> Ignite. We make do with CTR quite well.
>
>
> >  Also we have
> > really tough requirements for performance, stability, backward
> > compatibility, etc...
>
> Write them down. Make sure new contributors understand them before
> offering them commit access. That's a prerequisite for growing an open
> community anyway.
>
> > Having said that it is really easy to break something
> > even with minor change like switching type of collection to another one.
>
> So? Stuff like that should be documented in the code, if it isn't no
> amount of prior review will help, since how do you know that the
> reviewer happens to remember such details a few years from now?
>
> > And I personally feel safer when my code has been reviewed before I merge
> > it to master.
>
> So ask for a review if you think you need it. I never said *all* reviews
> should be post-commit: I said that the default mode should be CTR and
> it's up to the developer to ask for more eyes on their code.
>
> > Also when thousand lines change set is merged and there are
> > conflicting change sets merged after, it is quite hard to rollback this
> > first change if it was wrong. And we have conflicting changes all the time.
>
> Apparently you need to learn to use the version control tool you
> selected, or adjust your workflows for the failings of said tool. Or
> change the tool, who knows, you might find that's a good move. :)
>
> Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> on the development branch, not on the mainline: the workflow should be:
>
>  1. create branch from mainline
>  2. make changes on branch
>  3. merge mainline to branch and resolve conflicts (repeat as needed)
>  4. run tests on branch code
>  5. merge branch to mainline
>
> Skipping step 3 (and 4) is going to be a constant pain regardless of
> which tool you use. Also for trivial changes it makes no sense at all to
> even create a branch; just fix it on the mainline, your version history
> will be a lot easier to follow.
>
> > My opinion is that correct trade off for us now is having slower but more
> > predictable development. RTC approach here definitely fits better.
>
> RTC has an additional problem that it can (and often does; look at one
> of the most famous ASF projects if you don't believe me) create tensions
> in the community. It makes sense to use it for maintenance branches, but
> not for new development.

Needless to say, I agree with everything just said (except for the VCS change
proposition, which I found to be outright crazy, of course ;)

And to pile more on top: I've experienced the consequences of the very
situation, described in the very last paragraph. The RTC lead to a totally
nuts situation in Hadoop, where fellas who wanted to reject a small patch, not
based on the technical merits of the fix, had came up with an excuse that the
reviewer (a full committer) didn't have enough expertise to review the code in
question. The silliness was quickly put down by the sane community members,
but you see where I am going with it...

In other words: if you don't trust a committer to make the changes in the VCS
system - that committer shouldn't be having the commit-bit in the first place.
Intricacies of roll-backs aren't an excuse and most often than not could be
fixed by changing the process hygiene. CTR attitude leads, in general, to a
higher quality of the contribution because ppl are trying to avoid public
scolding, inevitable in case of forced-reverts. With RTC the blame would be
shared between the author and the reviewer, which make situation more bearable
(falsely, of course). And guess what - reviewers are humans and make mistakes
all the time, but that was already pointed out.

Cos

[Alexey Kuznetsov-2]

In my experience RTC is better.

As I can see Ignite evolving very fast  with this model.
Why some one expects that RTC will slow down development?

I'm for RTC.

On Tue, Jul 28, 2015 at 6:30 AM, Konstantin Boudnik <[hidden email]> wrote:

> On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > Guys,
> > >
> > > I would say Ignite is quite a big and quite complex project.
> >
> > This has absolutely nothing to do with trusting developers. FWIW,
> > Subversion is also very complex, I'll dare say that its object model and
> > working copy semantics are more convoluted than anything you'll find in
> > Ignite. We make do with CTR quite well.
> >
> >
> > >  Also we have
> > > really tough requirements for performance, stability, backward
> > > compatibility, etc...
> >
> > Write them down. Make sure new contributors understand them before
> > offering them commit access. That's a prerequisite for growing an open
> > community anyway.
> >
> > > Having said that it is really easy to break something
> > > even with minor change like switching type of collection to another
> one.
> >
> > So? Stuff like that should be documented in the code, if it isn't no
> > amount of prior review will help, since how do you know that the
> > reviewer happens to remember such details a few years from now?
> >
> > > And I personally feel safer when my code has been reviewed before I
> merge
> > > it to master.
> >
> > So ask for a review if you think you need it. I never said *all* reviews
> > should be post-commit: I said that the default mode should be CTR and
> > it's up to the developer to ask for more eyes on their code.
> >
> > > Also when thousand lines change set is merged and there are
> > > conflicting change sets merged after, it is quite hard to rollback this
> > > first change if it was wrong. And we have conflicting changes all the
> time.
> >
> > Apparently you need to learn to use the version control tool you
> > selected, or adjust your workflows for the failings of said tool. Or
> > change the tool, who knows, you might find that's a good move. :)
> >
> > Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> > on the development branch, not on the mainline: the workflow should be:
> >
> >  1. create branch from mainline
> >  2. make changes on branch
> >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> >  4. run tests on branch code
> >  5. merge branch to mainline
> >
> > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > which tool you use. Also for trivial changes it makes no sense at all to
> > even create a branch; just fix it on the mainline, your version history
> > will be a lot easier to follow.
> >
> > > My opinion is that correct trade off for us now is having slower but
> more
> > > predictable development. RTC approach here definitely fits better.
> >
> > RTC has an additional problem that it can (and often does; look at one
> > of the most famous ASF projects if you don't believe me) create tensions
> > in the community. It makes sense to use it for maintenance branches, but
> > not for new development.
>
> Needless to say, I agree with everything just said (except for the VCS
> change
> proposition, which I found to be outright crazy, of course ;)
>
> And to pile more on top: I've experienced the consequences of the very
> situation, described in the very last paragraph. The RTC lead to a totally
> nuts situation in Hadoop, where fellas who wanted to reject a small patch,
> not
> based on the technical merits of the fix, had came up with an excuse that
> the
> reviewer (a full committer) didn't have enough expertise to review the
> code in
> question. The silliness was quickly put down by the sane community members,
> but you see where I am going with it...
>
> In other words: if you don't trust a committer to make the changes in the
> VCS
> system - that committer shouldn't be having the commit-bit in the first
> place.
> Intricacies of roll-backs aren't an excuse and most often than not could be
> fixed by changing the process hygiene. CTR attitude leads, in general, to a
> higher quality of the contribution because ppl are trying to avoid public
> scolding, inevitable in case of forced-reverts. With RTC the blame would be
> shared between the author and the reviewer, which make situation more
> bearable
> (falsely, of course). And guess what - reviewers are humans and make
> mistakes
> all the time, but that was already pointed out.
>
> Cos
>
>

--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[dsetrakyan]

I want to address the following point made by Brane and Cos:
----

*if you don't trust a committer to make the changes in the VCSsystem - that
committer shouldn't be having the commit-bit in the first place.*
----

I don't believe this point actually applies to Ignite.

As all of us are aware, Ignite has a very lightweight process for a
contributor to become a committer. Essentially, once any type of
contribution is accepted, even a 1-liner, a contributor is eligible to
become a committer.

Such process was put in place to ensure that community can grow faster, and
allows new members to quickly start contributing in a more meaningful way.
Consequently, the same policy will result in some not-so-experienced
committers joining the project.

I personally like the fact that we have a very easy path for the new-comers
to join. However, for as long as we have this policy, I believe that RTC
remains a better approach for us.

Having said that, I would agree that certain trivial fixes can be made
directly in the master branch. For example, simple documentation or test
updates, IMHO, would fit into this category, as long as an email is sent to
the dev list notifying the rest of the community about the change.

D.

On Mon, Jul 27, 2015 at 4:30 PM, Konstantin Boudnik <[hidden email]> wrote:

> On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > Guys,
> > >
> > > I would say Ignite is quite a big and quite complex project.
> >
> > This has absolutely nothing to do with trusting developers. FWIW,
> > Subversion is also very complex, I'll dare say that its object model and
> > working copy semantics are more convoluted than anything you'll find in
> > Ignite. We make do with CTR quite well.
> >
> >
> > >  Also we have
> > > really tough requirements for performance, stability, backward
> > > compatibility, etc...
> >
> > Write them down. Make sure new contributors understand them before
> > offering them commit access. That's a prerequisite for growing an open
> > community anyway.
> >
> > > Having said that it is really easy to break something
> > > even with minor change like switching type of collection to another
> one.
> >
> > So? Stuff like that should be documented in the code, if it isn't no
> > amount of prior review will help, since how do you know that the
> > reviewer happens to remember such details a few years from now?
> >
> > > And I personally feel safer when my code has been reviewed before I
> merge
> > > it to master.
> >
> > So ask for a review if you think you need it. I never said *all* reviews
> > should be post-commit: I said that the default mode should be CTR and
> > it's up to the developer to ask for more eyes on their code.
> >
> > > Also when thousand lines change set is merged and there are
> > > conflicting change sets merged after, it is quite hard to rollback this
> > > first change if it was wrong. And we have conflicting changes all the
> time.
> >
> > Apparently you need to learn to use the version control tool you
> > selected, or adjust your workflows for the failings of said tool. Or
> > change the tool, who knows, you might find that's a good move. :)
> >
> > Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> > on the development branch, not on the mainline: the workflow should be:
> >
> >  1. create branch from mainline
> >  2. make changes on branch
> >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> >  4. run tests on branch code
> >  5. merge branch to mainline
> >
> > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > which tool you use. Also for trivial changes it makes no sense at all to
> > even create a branch; just fix it on the mainline, your version history
> > will be a lot easier to follow.
> >
> > > My opinion is that correct trade off for us now is having slower but
> more
> > > predictable development. RTC approach here definitely fits better.
> >
> > RTC has an additional problem that it can (and often does; look at one
> > of the most famous ASF projects if you don't believe me) create tensions
> > in the community. It makes sense to use it for maintenance branches, but
> > not for new development.
>
> Needless to say, I agree with everything just said (except for the VCS
> change
> proposition, which I found to be outright crazy, of course ;)
>
> And to pile more on top: I've experienced the consequences of the very
> situation, described in the very last paragraph. The RTC lead to a totally
> nuts situation in Hadoop, where fellas who wanted to reject a small patch,
> not
> based on the technical merits of the fix, had came up with an excuse that
> the
> reviewer (a full committer) didn't have enough expertise to review the
> code in
> question. The silliness was quickly put down by the sane community members,
> but you see where I am going with it...
>
> In other words: if you don't trust a committer to make the changes in the
> VCS
> system - that committer shouldn't be having the commit-bit in the first
> place.
> Intricacies of roll-backs aren't an excuse and most often than not could be
> fixed by changing the process hygiene. CTR attitude leads, in general, to a
> higher quality of the contribution because ppl are trying to avoid public
> scolding, inevitable in case of forced-reverts. With RTC the blame would be
> shared between the author and the reviewer, which make situation more
> bearable
> (falsely, of course). And guess what - reviewers are humans and make
> mistakes
> all the time, but that was already pointed out.
>
> Cos
>
>

[Valentin Kulichenko]

I tend to agree on points brought by Brane and Cos. Having a formality that
review is always required regardless of what the change actually implies
looks like an overkill.
At the same time, I usually feel uncomfortable without a review. Ignite is
not just a "complicated" project. It has a lot of concurrency issues (both
local and distributed) and a lot of components doing absolutely different
stuff, but highly integrated with each other. As a result, there are tons
of race conditions which CI will never check and it's really possible to
miss something.
I would follow (and would recommend to others) the RTC model in most cases,
but I don't need a formal rule for this.

-Val
On Jul 28, 2015 12:57 AM, "Dmitriy Setrakyan" <[hidden email]> wrote:

> I want to address the following point made by Brane and Cos:
> ----
>
> *if you don't trust a committer to make the changes in the VCSsystem - that
> committer shouldn't be having the commit-bit in the first place.*
> ----
>
> I don't believe this point actually applies to Ignite.
>
> As all of us are aware, Ignite has a very lightweight process for a
> contributor to become a committer. Essentially, once any type of
> contribution is accepted, even a 1-liner, a contributor is eligible to
> become a committer.
>
> Such process was put in place to ensure that community can grow faster, and
> allows new members to quickly start contributing in a more meaningful way.
> Consequently, the same policy will result in some not-so-experienced
> committers joining the project.
>
> I personally like the fact that we have a very easy path for the new-comers
> to join. However, for as long as we have this policy, I believe that RTC
> remains a better approach for us.
>
> Having said that, I would agree that certain trivial fixes can be made
> directly in the master branch. For example, simple documentation or test
> updates, IMHO, would fit into this category, as long as an email is sent to
> the dev list notifying the rest of the community about the change.
>
> D.
>
> On Mon, Jul 27, 2015 at 4:30 PM, Konstantin Boudnik <[hidden email]>
> wrote:
>
> > On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > > Guys,
> > > >
> > > > I would say Ignite is quite a big and quite complex project.
> > >
> > > This has absolutely nothing to do with trusting developers. FWIW,
> > > Subversion is also very complex, I'll dare say that its object model
> and
> > > working copy semantics are more convoluted than anything you'll find in
> > > Ignite. We make do with CTR quite well.
> > >
> > >
> > > >  Also we have
> > > > really tough requirements for performance, stability, backward
> > > > compatibility, etc...
> > >
> > > Write them down. Make sure new contributors understand them before
> > > offering them commit access. That's a prerequisite for growing an open
> > > community anyway.
> > >
> > > > Having said that it is really easy to break something
> > > > even with minor change like switching type of collection to another
> > one.
> > >
> > > So? Stuff like that should be documented in the code, if it isn't no
> > > amount of prior review will help, since how do you know that the
> > > reviewer happens to remember such details a few years from now?
> > >
> > > > And I personally feel safer when my code has been reviewed before I
> > merge
> > > > it to master.
> > >
> > > So ask for a review if you think you need it. I never said *all*
> reviews
> > > should be post-commit: I said that the default mode should be CTR and
> > > it's up to the developer to ask for more eyes on their code.
> > >
> > > > Also when thousand lines change set is merged and there are
> > > > conflicting change sets merged after, it is quite hard to rollback
> this
> > > > first change if it was wrong. And we have conflicting changes all the
> > time.
> > >
> > > Apparently you need to learn to use the version control tool you
> > > selected, or adjust your workflows for the failings of said tool. Or
> > > change the tool, who knows, you might find that's a good move. :)
> > >
> > > Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> > > on the development branch, not on the mainline: the workflow should be:
> > >
> > >  1. create branch from mainline
> > >  2. make changes on branch
> > >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> > >  4. run tests on branch code
> > >  5. merge branch to mainline
> > >
> > > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > > which tool you use. Also for trivial changes it makes no sense at all
> to
> > > even create a branch; just fix it on the mainline, your version history
> > > will be a lot easier to follow.
> > >
> > > > My opinion is that correct trade off for us now is having slower but
> > more
> > > > predictable development. RTC approach here definitely fits better.
> > >
> > > RTC has an additional problem that it can (and often does; look at one
> > > of the most famous ASF projects if you don't believe me) create
> tensions
> > > in the community. It makes sense to use it for maintenance branches,
> but
> > > not for new development.
> >
> > Needless to say, I agree with everything just said (except for the VCS
> > change
> > proposition, which I found to be outright crazy, of course ;)
> >
> > And to pile more on top: I've experienced the consequences of the very
> > situation, described in the very last paragraph. The RTC lead to a
> totally
> > nuts situation in Hadoop, where fellas who wanted to reject a small
> patch,
> > not
> > based on the technical merits of the fix, had came up with an excuse that
> > the
> > reviewer (a full committer) didn't have enough expertise to review the
> > code in
> > question. The silliness was quickly put down by the sane community
> members,
> > but you see where I am going with it...
> >
> > In other words: if you don't trust a committer to make the changes in the
> > VCS
> > system - that committer shouldn't be having the commit-bit in the first
> > place.
> > Intricacies of roll-backs aren't an excuse and most often than not could
> be
> > fixed by changing the process hygiene. CTR attitude leads, in general,
> to a
> > higher quality of the contribution because ppl are trying to avoid public
> > scolding, inevitable in case of forced-reverts. With RTC the blame would
> be
> > shared between the author and the reviewer, which make situation more
> > bearable
> > (falsely, of course). And guess what - reviewers are humans and make
> > mistakes
> > all the time, but that was already pointed out.
> >
> > Cos
> >
> >
>

[yzhdanov]

I am for RTC.

Agree with Val, that significant part of the concurrency issues are very
hard to catch with CI. They are caught on review (and some unfortunately
slip through). And Sergi's points seems very valid to me - complex changes
should be reviewed to make the best effort to avoid issues of any type.

I would encourage everyone to request review if:

   - core logic changed. Although it is very hard to define, but
   communication, discovery, cache, compute, deployment, continuous processes
   are on the list.
   - public APIs
   - new feature completed (in most cases it causes changes to public API)

The following can be committed to master right-away:

   - Javadocs
   - Comments
   - Typos
   - Fixes to tests

Let's summarize the points to some kind of guideline/hints and put it on
wiki.

--Yakov

2015-07-28 11:18 GMT+03:00 Valentin Kulichenko <
[hidden email]>:

> I tend to agree on points brought by Brane and Cos. Having a formality that
> review is always required regardless of what the change actually implies
> looks like an overkill.
> At the same time, I usually feel uncomfortable without a review. Ignite is
> not just a "complicated" project. It has a lot of concurrency issues (both
> local and distributed) and a lot of components doing absolutely different
> stuff, but highly integrated with each other. As a result, there are tons
> of race conditions which CI will never check and it's really possible to
> miss something.
> I would follow (and would recommend to others) the RTC model in most cases,
> but I don't need a formal rule for this.
>
> -Val
> On Jul 28, 2015 12:57 AM, "Dmitriy Setrakyan" <[hidden email]>
> wrote:
>
> > I want to address the following point made by Brane and Cos:
> > ----
> >
> > *if you don't trust a committer to make the changes in the VCSsystem -
> that
> > committer shouldn't be having the commit-bit in the first place.*
> > ----
> >
> > I don't believe this point actually applies to Ignite.
> >
> > As all of us are aware, Ignite has a very lightweight process for a
> > contributor to become a committer. Essentially, once any type of
> > contribution is accepted, even a 1-liner, a contributor is eligible to
> > become a committer.
> >
> > Such process was put in place to ensure that community can grow faster,
> and
> > allows new members to quickly start contributing in a more meaningful
> way.
> > Consequently, the same policy will result in some not-so-experienced
> > committers joining the project.
> >
> > I personally like the fact that we have a very easy path for the
> new-comers
> > to join. However, for as long as we have this policy, I believe that RTC
> > remains a better approach for us.
> >
> > Having said that, I would agree that certain trivial fixes can be made
> > directly in the master branch. For example, simple documentation or test
> > updates, IMHO, would fit into this category, as long as an email is sent
> to
> > the dev list notifying the rest of the community about the change.
> >
> > D.
> >
> > On Mon, Jul 27, 2015 at 4:30 PM, Konstantin Boudnik <[hidden email]>
> > wrote:
> >
> > > On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > > > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > > > Guys,
> > > > >
> > > > > I would say Ignite is quite a big and quite complex project.
> > > >
> > > > This has absolutely nothing to do with trusting developers. FWIW,
> > > > Subversion is also very complex, I'll dare say that its object model
> > and
> > > > working copy semantics are more convoluted than anything you'll find
> in
> > > > Ignite. We make do with CTR quite well.
> > > >
> > > >
> > > > >  Also we have
> > > > > really tough requirements for performance, stability, backward
> > > > > compatibility, etc...
> > > >
> > > > Write them down. Make sure new contributors understand them before
> > > > offering them commit access. That's a prerequisite for growing an
> open
> > > > community anyway.
> > > >
> > > > > Having said that it is really easy to break something
> > > > > even with minor change like switching type of collection to another
> > > one.
> > > >
> > > > So? Stuff like that should be documented in the code, if it isn't no
> > > > amount of prior review will help, since how do you know that the
> > > > reviewer happens to remember such details a few years from now?
> > > >
> > > > > And I personally feel safer when my code has been reviewed before I
> > > merge
> > > > > it to master.
> > > >
> > > > So ask for a review if you think you need it. I never said *all*
> > reviews
> > > > should be post-commit: I said that the default mode should be CTR and
> > > > it's up to the developer to ask for more eyes on their code.
> > > >
> > > > > Also when thousand lines change set is merged and there are
> > > > > conflicting change sets merged after, it is quite hard to rollback
> > this
> > > > > first change if it was wrong. And we have conflicting changes all
> the
> > > time.
> > > >
> > > > Apparently you need to learn to use the version control tool you
> > > > selected, or adjust your workflows for the failings of said tool. Or
> > > > change the tool, who knows, you might find that's a good move. :)
> > > >
> > > > Regardless of which tool you use, conflicts should *ALWAYS* be
> resolved
> > > > on the development branch, not on the mainline: the workflow should
> be:
> > > >
> > > >  1. create branch from mainline
> > > >  2. make changes on branch
> > > >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> > > >  4. run tests on branch code
> > > >  5. merge branch to mainline
> > > >
> > > > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > > > which tool you use. Also for trivial changes it makes no sense at all
> > to
> > > > even create a branch; just fix it on the mainline, your version
> history
> > > > will be a lot easier to follow.
> > > >
> > > > > My opinion is that correct trade off for us now is having slower
> but
> > > more
> > > > > predictable development. RTC approach here definitely fits better.
> > > >
> > > > RTC has an additional problem that it can (and often does; look at
> one
> > > > of the most famous ASF projects if you don't believe me) create
> > tensions
> > > > in the community. It makes sense to use it for maintenance branches,
> > but
> > > > not for new development.
> > >
> > > Needless to say, I agree with everything just said (except for the VCS
> > > change
> > > proposition, which I found to be outright crazy, of course ;)
> > >
> > > And to pile more on top: I've experienced the consequences of the very
> > > situation, described in the very last paragraph. The RTC lead to a
> > totally
> > > nuts situation in Hadoop, where fellas who wanted to reject a small
> > patch,
> > > not
> > > based on the technical merits of the fix, had came up with an excuse
> that
> > > the
> > > reviewer (a full committer) didn't have enough expertise to review the
> > > code in
> > > question. The silliness was quickly put down by the sane community
> > members,
> > > but you see where I am going with it...
> > >
> > > In other words: if you don't trust a committer to make the changes in
> the
> > > VCS
> > > system - that committer shouldn't be having the commit-bit in the first
> > > place.
> > > Intricacies of roll-backs aren't an excuse and most often than not
> could
> > be
> > > fixed by changing the process hygiene. CTR attitude leads, in general,
> > to a
> > > higher quality of the contribution because ppl are trying to avoid
> public
> > > scolding, inevitable in case of forced-reverts. With RTC the blame
> would
> > be
> > > shared between the author and the reviewer, which make situation more
> > > bearable
> > > (falsely, of course). And guess what - reviewers are humans and make
> > > mistakes
> > > all the time, but that was already pointed out.
> > >
> > > Cos
> > >
> > >
> >
>

[Branko Čibej]

On 28.07.2015 12:12, Yakov Zhdanov wrote:

> I am for RTC.
>
> Agree with Val, that significant part of the concurrency issues are very
> hard to catch with CI. They are caught on review (and some unfortunately
> slip through). And Sergi's points seems very valid to me - complex changes
> should be reviewed to make the best effort to avoid issues of any type.
>
> I would encourage everyone to request review if:
>
>    - core logic changed. Although it is very hard to define, but
>    communication, discovery, cache, compute, deployment, continuous processes
>    are on the list.
>    - public APIs
>    - new feature completed (in most cases it causes changes to public API)
>
> The following can be committed to master right-away:
>
>    - Javadocs
>    - Comments
>    - Typos
>    - Fixes to tests
>
> Let's summarize the points to some kind of guideline/hints and put it on
> wiki.

I agree about the guidelines, just don't make them rules. I still
maintain that the committer should be trusted to know when a prior
review is needed.

-- Brane

[Branko Čibej]

On 28.07.2015 09:56, Dmitriy Setrakyan wrote:

> I want to address the following point made by Brane and Cos:
> ----
>
> *if you don't trust a committer to make the changes in the VCSsystem - that
> committer shouldn't be having the commit-bit in the first place.*
> ----
>
> I don't believe this point actually applies to Ignite.
>
> As all of us are aware, Ignite has a very lightweight process for a
> contributor to become a committer. Essentially, once any type of
> contribution is accepted, even a 1-liner, a contributor is eligible to
> become a committer.

The PMC is responsible for the project. After graduation, you'll
probably have to think a bit more about criteria for becoming a
committer; after all, once the privilege has been given it's very, very
hard to take it away. Otherwise you could find yourselves bogged down in
a constant cycle of reviews and reverts and never get any work done.

I'm not saying you should suddenly put an enormous wall around the
project. The most important trait of a good community member isn't
experience or coding skill, it's good judgement.

-- Brane

[Vasilisa Sidorova]

In a perfect world I agree with Brane.

But there is top class from each igniter to trust each others on the 1000% and always to be ready that something go sideways. This process take time.

So I think that our Jira process should be flexible because Ignite is young project.

As a first step we can get together to commit simple fixes without review and take as a "simple" issues in Jira with "trivial" priority.

When our community credit of trust will grows up we can review Jira process and decide to take as a "simple" issues in Jira with "minor" priority or find some new solution.

Etc...

Regards,
Vasilisa

[Konstantin Boudnik-2]

On Tue, Jul 28, 2015 at 12:56AM, Dmitriy Setrakyan wrote:

> I want to address the following point made by Brane and Cos:
> ----
>
> *if you don't trust a committer to make the changes in the VCSsystem - that
> committer shouldn't be having the commit-bit in the first place.*
> ----
>
> I don't believe this point actually applies to Ignite.
>
> As all of us are aware, Ignite has a very lightweight process for a
> contributor to become a committer. Essentially, once any type of
> contribution is accepted, even a 1-liner, a contributor is eligible to
> become a committer.

Indeed so! But let's look a bit into the future, past the graduation and all.
It's unlikely that the same entrance criteria will remain in place for a TLP
project. Hence, the community will have a bigger set of facts to judge a new
contributor's qualities before extending the commit-bit.

Cos

> Such process was put in place to ensure that community can grow faster, and
> allows new members to quickly start contributing in a more meaningful way.
> Consequently, the same policy will result in some not-so-experienced
> committers joining the project.
>
> I personally like the fact that we have a very easy path for the new-comers
> to join. However, for as long as we have this policy, I believe that RTC
> remains a better approach for us.
>
> Having said that, I would agree that certain trivial fixes can be made
> directly in the master branch. For example, simple documentation or test
> updates, IMHO, would fit into this category, as long as an email is sent to
> the dev list notifying the rest of the community about the change.
>
> D.
>
> On Mon, Jul 27, 2015 at 4:30 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > > Guys,
> > > >
> > > > I would say Ignite is quite a big and quite complex project.
> > >
> > > This has absolutely nothing to do with trusting developers. FWIW,
> > > Subversion is also very complex, I'll dare say that its object model and
> > > working copy semantics are more convoluted than anything you'll find in
> > > Ignite. We make do with CTR quite well.
> > >
> > >
> > > >  Also we have
> > > > really tough requirements for performance, stability, backward
> > > > compatibility, etc...
> > >
> > > Write them down. Make sure new contributors understand them before
> > > offering them commit access. That's a prerequisite for growing an open
> > > community anyway.
> > >
> > > > Having said that it is really easy to break something
> > > > even with minor change like switching type of collection to another
> > one.
> > >
> > > So? Stuff like that should be documented in the code, if it isn't no
> > > amount of prior review will help, since how do you know that the
> > > reviewer happens to remember such details a few years from now?
> > >
> > > > And I personally feel safer when my code has been reviewed before I
> > merge
> > > > it to master.
> > >
> > > So ask for a review if you think you need it. I never said *all* reviews
> > > should be post-commit: I said that the default mode should be CTR and
> > > it's up to the developer to ask for more eyes on their code.
> > >
> > > > Also when thousand lines change set is merged and there are
> > > > conflicting change sets merged after, it is quite hard to rollback this
> > > > first change if it was wrong. And we have conflicting changes all the
> > time.
> > >
> > > Apparently you need to learn to use the version control tool you
> > > selected, or adjust your workflows for the failings of said tool. Or
> > > change the tool, who knows, you might find that's a good move. :)
> > >
> > > Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> > > on the development branch, not on the mainline: the workflow should be:
> > >
> > >  1. create branch from mainline
> > >  2. make changes on branch
> > >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> > >  4. run tests on branch code
> > >  5. merge branch to mainline
> > >
> > > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > > which tool you use. Also for trivial changes it makes no sense at all to
> > > even create a branch; just fix it on the mainline, your version history
> > > will be a lot easier to follow.
> > >
> > > > My opinion is that correct trade off for us now is having slower but
> > more
> > > > predictable development. RTC approach here definitely fits better.
> > >
> > > RTC has an additional problem that it can (and often does; look at one
> > > of the most famous ASF projects if you don't believe me) create tensions
> > > in the community. It makes sense to use it for maintenance branches, but
> > > not for new development.
> >
> > Needless to say, I agree with everything just said (except for the VCS
> > change
> > proposition, which I found to be outright crazy, of course ;)
> >
> > And to pile more on top: I've experienced the consequences of the very
> > situation, described in the very last paragraph. The RTC lead to a totally
> > nuts situation in Hadoop, where fellas who wanted to reject a small patch,
> > not
> > based on the technical merits of the fix, had came up with an excuse that
> > the
> > reviewer (a full committer) didn't have enough expertise to review the
> > code in
> > question. The silliness was quickly put down by the sane community members,
> > but you see where I am going with it...
> >
> > In other words: if you don't trust a committer to make the changes in the
> > VCS
> > system - that committer shouldn't be having the commit-bit in the first
> > place.
> > Intricacies of roll-backs aren't an excuse and most often than not could be
> > fixed by changing the process hygiene. CTR attitude leads, in general, to a
> > higher quality of the contribution because ppl are trying to avoid public
> > scolding, inevitable in case of forced-reverts. With RTC the blame would be
> > shared between the author and the reviewer, which make situation more
> > bearable
> > (falsely, of course). And guess what - reviewers are humans and make
> > mistakes
> > all the time, but that was already pointed out.
> >
> > Cos
> >
> >

[Konstantin Boudnik-2]

On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> In a perfect world I agree with Brane.
>
> But there is top class from each igniter to trust each others on the 1000%
> and always to be ready that something go sideways. This process take time.

Actually, no one is talking about 100% trust. That's why post-commit reviews
are welcome, and reverts aren't removed from the table as a faculty of last
resort.

We are talking about trusting a committer not to do silly things that break
the master. People will be making mistakes anyway; reviewers are people too
and will be making mistakes as well. There's no way to stop it: but there're
ways to mitigate the harm and to make sure bad commits are few and far apart.

Cos

> So I think that our Jira process should be flexible because Ignite is young
> project.
>
> As a first step we can get together to commit simple fixes without review
> and take as a "simple" issues in Jira with "trivial" priority.
>
> When our community credit of trust will grows up we can review Jira process
> and decide to take as a "simple" issues in Jira with "minor" priority or
> find some new solution.
>
> Etc...
>
> Regards,
> Vasilisa
>
>
>
> --
> View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[Vladimir Ozerov]

+1 for RTC. For now rules to become a committer are pretty "soft", CI and
JIRA processes are still changing, etc. I believe without additional
control quality of our product will deteriorate in such environment.

Let's graduate first, establish development processes, define requirements
to become a committer and only then start thinking about switching to CTR
which is for sure more suitable for well-established TLP.

On Tue, Jul 28, 2015 at 9:11 PM, Konstantin Boudnik <[hidden email]> wrote:

> On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> > In a perfect world I agree with Brane.
> >
> > But there is top class from each igniter to trust each others on the
> 1000%
> > and always to be ready that something go sideways. This process take
> time.
>
> Actually, no one is talking about 100% trust. That's why post-commit
> reviews
> are welcome, and reverts aren't removed from the table as a faculty of last
> resort.
>
> We are talking about trusting a committer not to do silly things that break
> the master. People will be making mistakes anyway; reviewers are people too
> and will be making mistakes as well. There's no way to stop it: but
> there're
> ways to mitigate the harm and to make sure bad commits are few and far
> apart.
>
> Cos
>
> > So I think that our Jira process should be flexible because Ignite is
> young
> > project.
> >
> > As a first step we can get together to commit simple fixes without review
> > and take as a "simple" issues in Jira with "trivial" priority.
> >
> > When our community credit of trust will grows up we can review Jira
> process
> > and decide to take as a "simple" issues in Jira with "minor" priority or
> > find some new solution.
> >
> > Etc...
> >
> > Regards,
> > Vasilisa
> >
> >
> >
> > --
> > View this message in context:
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
>

[dsetrakyan]

From what I am seeing, majority of community members are OK with CTR with a
suggestion that we raise the bar for becoming a committer into Ignite (this
will require a separate thread).

If there are no strong objections, let's give CTR a shot. We can always
come back to this discussion if needed.

I have added "Commit-Then-Review" section to Jira process:
https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process

Feel free to comment.

D.

On Tue, Jul 28, 2015 at 11:17 AM, Vladimir Ozerov <[hidden email]>
wrote:

> +1 for RTC. For now rules to become a committer are pretty "soft", CI and
> JIRA processes are still changing, etc. I believe without additional
> control quality of our product will deteriorate in such environment.
>
> Let's graduate first, establish development processes, define requirements
> to become a committer and only then start thinking about switching to CTR
> which is for sure more suitable for well-established TLP.
>
> On Tue, Jul 28, 2015 at 9:11 PM, Konstantin Boudnik <[hidden email]>
> wrote:
>
> > On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> > > In a perfect world I agree with Brane.
> > >
> > > But there is top class from each igniter to trust each others on the
> > 1000%
> > > and always to be ready that something go sideways. This process take
> > time.
> >
> > Actually, no one is talking about 100% trust. That's why post-commit
> > reviews
> > are welcome, and reverts aren't removed from the table as a faculty of
> last
> > resort.
> >
> > We are talking about trusting a committer not to do silly things that
> break
> > the master. People will be making mistakes anyway; reviewers are people
> too
> > and will be making mistakes as well. There's no way to stop it: but
> > there're
> > ways to mitigate the harm and to make sure bad commits are few and far
> > apart.
> >
> > Cos
> >
> > > So I think that our Jira process should be flexible because Ignite is
> > young
> > > project.
> > >
> > > As a first step we can get together to commit simple fixes without
> review
> > > and take as a "simple" issues in Jira with "trivial" priority.
> > >
> > > When our community credit of trust will grows up we can review Jira
> > process
> > > and decide to take as a "simple" issues in Jira with "minor" priority
> or
> > > find some new solution.
> > >
> > > Etc...
> > >
> > > Regards,
> > > Vasilisa
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> >
>

[Konstantin Boudnik-2]

I've just realized that I haven't read this one on time. It's been over a
month now and looks like nothing has been terminally broken just yet, right?


Cos

On Mon, Aug 03, 2015 at 02:43AM, Dmitriy Setrakyan wrote:

> From what I am seeing, majority of community members are OK with CTR with a
> suggestion that we raise the bar for becoming a committer into Ignite (this
> will require a separate thread).
>
> If there are no strong objections, let's give CTR a shot. We can always
> come back to this discussion if needed.
>
> I have added "Commit-Then-Review" section to Jira process:
> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>
> Feel free to comment.
>
> D.
>
> On Tue, Jul 28, 2015 at 11:17 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > +1 for RTC. For now rules to become a committer are pretty "soft", CI and
> > JIRA processes are still changing, etc. I believe without additional
> > control quality of our product will deteriorate in such environment.
> >
> > Let's graduate first, establish development processes, define requirements
> > to become a committer and only then start thinking about switching to CTR
> > which is for sure more suitable for well-established TLP.
> >
> > On Tue, Jul 28, 2015 at 9:11 PM, Konstantin Boudnik <[hidden email]>
> > wrote:
> >
> > > On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> > > > In a perfect world I agree with Brane.
> > > >
> > > > But there is top class from each igniter to trust each others on the
> > > 1000%
> > > > and always to be ready that something go sideways. This process take
> > > time.
> > >
> > > Actually, no one is talking about 100% trust. That's why post-commit
> > > reviews
> > > are welcome, and reverts aren't removed from the table as a faculty of
> > last
> > > resort.
> > >
> > > We are talking about trusting a committer not to do silly things that
> > break
> > > the master. People will be making mistakes anyway; reviewers are people
> > too
> > > and will be making mistakes as well. There's no way to stop it: but
> > > there're
> > > ways to mitigate the harm and to make sure bad commits are few and far
> > > apart.
> > >
> > > Cos
> > >
> > > > So I think that our Jira process should be flexible because Ignite is
> > > young
> > > > project.
> > > >
> > > > As a first step we can get together to commit simple fixes without
> > review
> > > > and take as a "simple" issues in Jira with "trivial" priority.
> > > >
> > > > When our community credit of trust will grows up we can review Jira
> > > process
> > > > and decide to take as a "simple" issues in Jira with "minor" priority
> > or
> > > > find some new solution.
> > > >
> > > > Etc...
> > > >
> > > > Regards,
> > > > Vasilisa
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html
> > > > Sent from the Apache Ignite Developers mailing list archive at
> > > Nabble.com.
> > >
> >

[dsetrakyan]

Nothing terminally broken. There were a couple of incorrect merges to
master, but it's a simple matter of getting used to the process I think.

On Sun, Sep 13, 2015 at 4:36 PM, Konstantin Boudnik <[hidden email]> wrote:

> I've just realized that I haven't read this one on time. It's been over a
> month now and looks like nothing has been terminally broken just yet,
> right?
>
>
> Cos
>
> On Mon, Aug 03, 2015 at 02:43AM, Dmitriy Setrakyan wrote:
> > From what I am seeing, majority of community members are OK with CTR
> with a
> > suggestion that we raise the bar for becoming a committer into Ignite
> (this
> > will require a separate thread).
> >
> > If there are no strong objections, let's give CTR a shot. We can always
> > come back to this discussion if needed.
> >
> > I have added "Commit-Then-Review" section to Jira process:
> > https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> >
> > Feel free to comment.
> >
> > D.
> >
> > On Tue, Jul 28, 2015 at 11:17 AM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > +1 for RTC. For now rules to become a committer are pretty "soft", CI
> and
> > > JIRA processes are still changing, etc. I believe without additional
> > > control quality of our product will deteriorate in such environment.
> > >
> > > Let's graduate first, establish development processes, define
> requirements
> > > to become a committer and only then start thinking about switching to
> CTR
> > > which is for sure more suitable for well-established TLP.
> > >
> > > On Tue, Jul 28, 2015 at 9:11 PM, Konstantin Boudnik <[hidden email]>
> > > wrote:
> > >
> > > > On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> > > > > In a perfect world I agree with Brane.
> > > > >
> > > > > But there is top class from each igniter to trust each others on
> the
> > > > 1000%
> > > > > and always to be ready that something go sideways. This process
> take
> > > > time.
> > > >
> > > > Actually, no one is talking about 100% trust. That's why post-commit
> > > > reviews
> > > > are welcome, and reverts aren't removed from the table as a faculty
> of
> > > last
> > > > resort.
> > > >
> > > > We are talking about trusting a committer not to do silly things that
> > > break
> > > > the master. People will be making mistakes anyway; reviewers are
> people
> > > too
> > > > and will be making mistakes as well. There's no way to stop it: but
> > > > there're
> > > > ways to mitigate the harm and to make sure bad commits are few and
> far
> > > > apart.
> > > >
> > > > Cos
> > > >
> > > > > So I think that our Jira process should be flexible because Ignite
> is
> > > > young
> > > > > project.
> > > > >
> > > > > As a first step we can get together to commit simple fixes without
> > > review
> > > > > and take as a "simple" issues in Jira with "trivial" priority.
> > > > >
> > > > > When our community credit of trust will grows up we can review Jira
> > > > process
> > > > > and decide to take as a "simple" issues in Jira with "minor"
> priority
> > > or
> > > > > find some new solution.
> > > > >
> > > > > Etc...
> > > > >
> > > > > Regards,
> > > > > Vasilisa
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1917.html
> > > > > Sent from the Apache Ignite Developers mailing list archive at
> > > > Nabble.com.
> > > >
> > >
>