You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Dmitriy Setrakyan <ds...@apache.org> on 2015/07/27 07:04:03 UTC
Jira Process
Igniters,
I believe several very valid points have been made on the general@ list
about our Jira handling, and how we should improve our Jira process.
I have tried to outline the Jira Process we should follow on our Wiki:
https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
Please review and provide comments. Let's try to finalize it within the
next couple of days.
D.
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <co...@apache.org> 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 <vo...@gridgain.com>
> > 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 <co...@apache.org>
> > > 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.
> > > >
> > >
>
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
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 <vo...@gridgain.com>
> 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 <co...@apache.org>
> > 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.
> > >
> >
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
>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 <vo...@gridgain.com>
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 <co...@apache.org>
> 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.
> >
>
Re: Jira Process
Posted by Vladimir Ozerov <vo...@gridgain.com>.
+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 <co...@apache.org> 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.
>
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
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.
Re: Jira Process
Posted by Vasilisa Sidorova <vs...@gridgain.com>.
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
--
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.
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
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 <co...@apache.org> 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
> >
> >
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
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
Re: Jira Process
Posted by Yakov Zhdanov <yz...@apache.org>.
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 <
valentin.kulichenko@gmail.com>:
> 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" <ds...@apache.org>
> 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 <co...@apache.org>
> > 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
> > >
> > >
> >
>
Re: Jira Process
Posted by Valentin Kulichenko <va...@gmail.com>.
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" <ds...@apache.org> 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 <co...@apache.org>
> 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
> >
> >
>
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
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
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <co...@apache.org> 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
>
>
Re: Jira Process
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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 <co...@apache.org> 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
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
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
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
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 <co...@apache.org>:
>
> >
> >
> > On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <br...@apache.org> wrote:
> > >On 27.07.2015 09:43, Atri Sharma wrote:
> > >> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org>
> > >wrote:
> > >>
> > >>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> > >>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org>
> > >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.
> >
> >
> >
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
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
Re: Jira Process
Posted by Sergi Vladykin <se...@gmail.com>.
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 <co...@apache.org>:
>
>
> On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <br...@apache.org> wrote:
> >On 27.07.2015 09:43, Atri Sharma wrote:
> >> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org>
> >wrote:
> >>
> >>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> >>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org>
> >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.
>
>
>
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <br...@apache.org> wrote:
>On 27.07.2015 09:43, Atri Sharma wrote:
>> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org>
>wrote:
>>
>>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
>>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org>
>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.
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 09:43, Atri Sharma wrote:
> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org> wrote:
>
>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org> 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.
-- Brane
Re: Jira Process
Posted by Atri Sharma <at...@gmail.com>.
On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org> wrote:
> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> > On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org> 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.
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org> 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.
-- Brane
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org> 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. However, as I suggested in
my other email, I am happy to switch to CTR for simple fixes, as long as we
have some definition of what *simple* means.
>
> -- Brane
>
>
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 09:17, Atri Sharma wrote:
> On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
>> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@apache.org> wrote:
>>
>>> On 27.07.2015 08:49, Atri Sharma wrote:
>>>> I totally agree on this one.
>>>>
>>>> In PostgreSQL, every committer's major changes are normally reviewed by
>>>> somebody else before the committer pushes the patch. However, for
>> trivial
>>>> patches, committer normally puts post on developer list stating his
>>> changes
>>>> and gives a timeline by which he/she will commit patch and objections
>>> need
>>>> to come before that. Giving a day for such patches should be fine, IMO.
>>> Well, over at Subversion, we regularly make major changes on trunk
>>> without previous review. Our only requirement is that trunk remains
>>> "stable", i.e., that tests pass; even then, no-one is expected to run
>>> tests on all supported platforms. Review happens after commit. Sure that
>>> means occasional bugs creep in, but that would happen regardless.
>>>
>>> If we imposed RTC, development of Subversion would literally grind to a
>>> stop. Developers are volunteers, so they review when they have time,
>>> which sometimes means a week or more after the actual commit.
>>>
>>> Note that for backports to stable release branches, we do have an RTC
>>> process in place.
>>>
>> Can you describe at which point a master becomes a release branch in
>> Subversion? Also, what happens if an occasional bad commit sneaked into the
>> release branch?
>>
>>
> As someone who has seen problems with bad commits, I totally second
> Dmitriy. Developer bugs be better caught and prevented rather than
> backpatched and fixed.
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.
-- Brane
Re: Jira Process
Posted by Atri Sharma <at...@gmail.com>.
On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@apache.org> wrote:
>
> > On 27.07.2015 08:49, Atri Sharma wrote:
> > > I totally agree on this one.
> > >
> > > In PostgreSQL, every committer's major changes are normally reviewed by
> > > somebody else before the committer pushes the patch. However, for
> trivial
> > > patches, committer normally puts post on developer list stating his
> > changes
> > > and gives a timeline by which he/she will commit patch and objections
> > need
> > > to come before that. Giving a day for such patches should be fine, IMO.
> >
> > Well, over at Subversion, we regularly make major changes on trunk
> > without previous review. Our only requirement is that trunk remains
> > "stable", i.e., that tests pass; even then, no-one is expected to run
> > tests on all supported platforms. Review happens after commit. Sure that
> > means occasional bugs creep in, but that would happen regardless.
> >
> > If we imposed RTC, development of Subversion would literally grind to a
> > stop. Developers are volunteers, so they review when they have time,
> > which sometimes means a week or more after the actual commit.
> >
> > Note that for backports to stable release branches, we do have an RTC
> > process in place.
> >
>
> Can you describe at which point a master becomes a release branch in
> Subversion? Also, what happens if an occasional bad commit sneaked into the
> release branch?
>
>
As someone who has seen problems with bad commits, I totally second
Dmitriy. Developer bugs be better caught and prevented rather than
backpatched and fixed.
>
> > Please don't go all control-freak on the source: it should be more than
> > enough to have a working CI, perform post-commit reviews and to run
> > tests on releases.
> >
>
> Not trying to... I was merely describing the dev process as of today.
> However, I am not seeing how a post-commit review speeds up the process.
> The review still occurs regardless, so why not do a pre-commit review to be
> safer?
>
Unless its a critical patch, I totally agree with Dmitriy here.
Re: Jira Process
Posted by Atri Sharma <at...@gmail.com>.
On Mon, Jul 27, 2015 at 1:03 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <br...@apache.org> wrote:
>
> > > Can you describe at which point a master becomes a release branch in
> > > Subversion?
> >
> > http://subversion.apache.org/docs/community-guide/releasing.html
> >
> > > Also, what happens if an occasional bad commit sneaked into the release
> > branch?
> >
> > It's almost impossible for that to happen, as per the process described
> > on that page. But if it does, we just revert it and try again, usually
> > after creating or fixing a backport branch.
> >
>
> I kind of see the point of bypassing reviews on simple fixes. However,
> *simple* is a relative term. I think we should define what *simple* means.
> I have some ideas, but I would like to hear some other opinions as well.
>
>
For me, simple is anything which is obvious to larger part of community. A
complex bug fix or a feature is not simple, but using the correct
Collection method (or the more efficient one) is.
Thoughts?
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 09:33, Dmitriy Setrakyan wrote:
> On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <br...@apache.org> wrote:
>
>>> Can you describe at which point a master becomes a release branch in
>>> Subversion?
>> http://subversion.apache.org/docs/community-guide/releasing.html
>>
>>> Also, what happens if an occasional bad commit sneaked into the release
>> branch?
>>
>> It's almost impossible for that to happen, as per the process described
>> on that page. But if it does, we just revert it and try again, usually
>> after creating or fixing a backport branch.
>>
> I kind of see the point of bypassing reviews on simple fixes. However,
> *simple* is a relative term. I think we should define what *simple* means.
> I have some ideas, but I would like to hear some other opinions as well.
Why not just trust developers to have a brain and use it? I don't expect
*you* need a document to decide which of your changes needs peer review;
so why expect that other committers need such a document? Just apply
good judgement, guys.
To be clear: someone who cannot make such a judgement call is failing a
fundamental requirement for committer status, IMNSHO.
-- Brane
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <br...@apache.org> wrote:
> > Can you describe at which point a master becomes a release branch in
> > Subversion?
>
> http://subversion.apache.org/docs/community-guide/releasing.html
>
> > Also, what happens if an occasional bad commit sneaked into the release
> branch?
>
> It's almost impossible for that to happen, as per the process described
> on that page. But if it does, we just revert it and try again, usually
> after creating or fixing a backport branch.
>
I kind of see the point of bypassing reviews on simple fixes. However,
*simple* is a relative term. I think we should define what *simple* means.
I have some ideas, but I would like to hear some other opinions as well.
> -- Brane
>
>
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 09:12, Dmitriy Setrakyan wrote:
> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@apache.org> wrote:
>
>> On 27.07.2015 08:49, Atri Sharma wrote:
>>> I totally agree on this one.
>>>
>>> In PostgreSQL, every committer's major changes are normally reviewed by
>>> somebody else before the committer pushes the patch. However, for trivial
>>> patches, committer normally puts post on developer list stating his
>> changes
>>> and gives a timeline by which he/she will commit patch and objections
>> need
>>> to come before that. Giving a day for such patches should be fine, IMO.
>> Well, over at Subversion, we regularly make major changes on trunk
>> without previous review. Our only requirement is that trunk remains
>> "stable", i.e., that tests pass; even then, no-one is expected to run
>> tests on all supported platforms. Review happens after commit. Sure that
>> means occasional bugs creep in, but that would happen regardless.
>>
>> If we imposed RTC, development of Subversion would literally grind to a
>> stop. Developers are volunteers, so they review when they have time,
>> which sometimes means a week or more after the actual commit.
>>
>> Note that for backports to stable release branches, we do have an RTC
>> process in place.
>>
> Can you describe at which point a master becomes a release branch in
> Subversion?
http://subversion.apache.org/docs/community-guide/releasing.html
> Also, what happens if an occasional bad commit sneaked into the release branch?
It's almost impossible for that to happen, as per the process described
on that page. But if it does, we just revert it and try again, usually
after creating or fixing a backport branch.
-- Brane
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@apache.org> wrote:
> On 27.07.2015 08:49, Atri Sharma wrote:
> > I totally agree on this one.
> >
> > In PostgreSQL, every committer's major changes are normally reviewed by
> > somebody else before the committer pushes the patch. However, for trivial
> > patches, committer normally puts post on developer list stating his
> changes
> > and gives a timeline by which he/she will commit patch and objections
> need
> > to come before that. Giving a day for such patches should be fine, IMO.
>
> Well, over at Subversion, we regularly make major changes on trunk
> without previous review. Our only requirement is that trunk remains
> "stable", i.e., that tests pass; even then, no-one is expected to run
> tests on all supported platforms. Review happens after commit. Sure that
> means occasional bugs creep in, but that would happen regardless.
>
> If we imposed RTC, development of Subversion would literally grind to a
> stop. Developers are volunteers, so they review when they have time,
> which sometimes means a week or more after the actual commit.
>
> Note that for backports to stable release branches, we do have an RTC
> process in place.
>
Can you describe at which point a master becomes a release branch in
Subversion? Also, what happens if an occasional bad commit sneaked into the
release branch?
> Please don't go all control-freak on the source: it should be more than
> enough to have a working CI, perform post-commit reviews and to run
> tests on releases.
>
Not trying to... I was merely describing the dev process as of today.
However, I am not seeing how a post-commit review speeds up the process.
The review still occurs regardless, so why not do a pre-commit review to be
safer?
>
> -- Brane
>
> > On Mon, Jul 27, 2015 at 12:15 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> >> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>
> >>> I second.
> >>>
> >>> It's up to the community to go CTR or RTC but former has a way more
> >>> flexibility and way speedier. Esp. considering that Ignite has great
> and
> >>> functional CI in place. We are trying to get CTR running in Bigtop, but
> >>> getting blocked by comprehensive CI being not ready yet.
> >>>
> >> The process in Ignite is that all committers work in separate branches.
> >> Committers are free to commit into their branch as often as required.
> >> However, the process that I prefer is that a review by another committer
> >> must happen before a final merge to the master takes place.
> >>
> >> In my experience, I have seen the simplest of the commits break builds
> or
> >> make wrong assumptions.
> >>
> >>
> >>> Please consider the consequences of the decision you're about to make.
> >>>
> >> I was hoping to arrive to a decision as a result of this discussion.
> >>
> >>
> >>> Cos
> >>>
> >>> On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <br...@apache.org>
> >> wrote:
> >>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> >>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org>
> >>>> wrote:
> >>>>>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> >>>>>>> Igniters,
> >>>>>>>
> >>>>>>> I believe several very valid points have been made on the general@
> >>>> list
> >>>>>>> about our Jira handling, and how we should improve our Jira
> >>>> process.
> >>>>>>> I have tried to outline the Jira Process we should follow on our
> >>>> Wiki:
> >>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> >>>>>>>
> >>>>>>> Please review and provide comments. Let's try to finalize it within
> >>>> the
> >>>>>>> next couple of days.
> >>>>>> This describes a commit-then-review process. This is absolutely not
> >>>> what
> >>>>>> you want. There is no need to ask for patch review before
> >>>> committing;
> >>>>>> this should happen after commit. The only case where the ticket
> >>>> review
> >>>>>> stage makes sense is when someone who is not a committer is writing
> >>>> the
> >>>>>> patch; or when the committer feels she needs extra eyes on the
> >>>> change.
> >>>>> Brane, I am not sure if I understood you correctly. The process that
> >>>> I
> >>>>> would like to see in Ignite is that absolutely every ticket undergoes
> >>>> a
> >>>>> review process before it gets merged to the main master branch,
> >>>> regardless
> >>>>> of whether it is done by a committer or not.
> >>>>>
> >>>>> Are you suggesting that the review process for committers should be
> >>>>> optional?
> >>>> Yes of course. The default process for making changes should be:
> >>>> commit,
> >>>> then review (CTR). This means that any committer can make any change
> >>>> without asking for a review first, and other committers review the
> >>>> changes after the commit.
> >>>>
> >>>> What you're proposing is the review, then commit (RTC) process, which
> >>>> a)
> >>>> implies that you don't trust committers even for trivial changes, b)
> >>>> slows down development and c) IMO is contrary to the spirit of open
> >>>> source. A committer should know when a change really needs review
> >>>> before
> >>>> committing, otherwise you shouldn't have made her a committer in the
> >>>> first place.
> >>>>
> >>>> My point in that discussion thread is that you guys are using Jira far
> >>>> too much for trivial stuff. It's a waste of time and resources to go
> >>>> through all the Jira steps for simple changes; instead, you should
> >>>> learn
> >>>> to write descriptive commit log messages and use Jira only for
> tracking
> >>>> large changes or bugs that can't be addressed immediately.
> >>>>
> >>>>
> >>>> As it stands, you're proposing to change an open development process
> >>>> into a bureaucratic nightmare. Please don't.
> >>>>
> >>>> -- Brane
> >
> >
>
>
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 08:49, Atri Sharma wrote:
> I totally agree on this one.
>
> In PostgreSQL, every committer's major changes are normally reviewed by
> somebody else before the committer pushes the patch. However, for trivial
> patches, committer normally puts post on developer list stating his changes
> and gives a timeline by which he/she will commit patch and objections need
> to come before that. Giving a day for such patches should be fine, IMO.
Well, over at Subversion, we regularly make major changes on trunk
without previous review. Our only requirement is that trunk remains
"stable", i.e., that tests pass; even then, no-one is expected to run
tests on all supported platforms. Review happens after commit. Sure that
means occasional bugs creep in, but that would happen regardless.
If we imposed RTC, development of Subversion would literally grind to a
stop. Developers are volunteers, so they review when they have time,
which sometimes means a week or more after the actual commit.
Note that for backports to stable release branches, we do have an RTC
process in place.
Please don't go all control-freak on the source: it should be more than
enough to have a working CI, perform post-commit reviews and to run
tests on releases.
-- Brane
> On Mon, Jul 27, 2015 at 12:15 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
>> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>
>>> I second.
>>>
>>> It's up to the community to go CTR or RTC but former has a way more
>>> flexibility and way speedier. Esp. considering that Ignite has great and
>>> functional CI in place. We are trying to get CTR running in Bigtop, but
>>> getting blocked by comprehensive CI being not ready yet.
>>>
>> The process in Ignite is that all committers work in separate branches.
>> Committers are free to commit into their branch as often as required.
>> However, the process that I prefer is that a review by another committer
>> must happen before a final merge to the master takes place.
>>
>> In my experience, I have seen the simplest of the commits break builds or
>> make wrong assumptions.
>>
>>
>>> Please consider the consequences of the decision you're about to make.
>>>
>> I was hoping to arrive to a decision as a result of this discussion.
>>
>>
>>> Cos
>>>
>>> On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <br...@apache.org>
>> wrote:
>>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
>>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org>
>>>> wrote:
>>>>>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
>>>>>>> Igniters,
>>>>>>>
>>>>>>> I believe several very valid points have been made on the general@
>>>> list
>>>>>>> about our Jira handling, and how we should improve our Jira
>>>> process.
>>>>>>> I have tried to outline the Jira Process we should follow on our
>>>> Wiki:
>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>>>>>>>
>>>>>>> Please review and provide comments. Let's try to finalize it within
>>>> the
>>>>>>> next couple of days.
>>>>>> This describes a commit-then-review process. This is absolutely not
>>>> what
>>>>>> you want. There is no need to ask for patch review before
>>>> committing;
>>>>>> this should happen after commit. The only case where the ticket
>>>> review
>>>>>> stage makes sense is when someone who is not a committer is writing
>>>> the
>>>>>> patch; or when the committer feels she needs extra eyes on the
>>>> change.
>>>>> Brane, I am not sure if I understood you correctly. The process that
>>>> I
>>>>> would like to see in Ignite is that absolutely every ticket undergoes
>>>> a
>>>>> review process before it gets merged to the main master branch,
>>>> regardless
>>>>> of whether it is done by a committer or not.
>>>>>
>>>>> Are you suggesting that the review process for committers should be
>>>>> optional?
>>>> Yes of course. The default process for making changes should be:
>>>> commit,
>>>> then review (CTR). This means that any committer can make any change
>>>> without asking for a review first, and other committers review the
>>>> changes after the commit.
>>>>
>>>> What you're proposing is the review, then commit (RTC) process, which
>>>> a)
>>>> implies that you don't trust committers even for trivial changes, b)
>>>> slows down development and c) IMO is contrary to the spirit of open
>>>> source. A committer should know when a change really needs review
>>>> before
>>>> committing, otherwise you shouldn't have made her a committer in the
>>>> first place.
>>>>
>>>> My point in that discussion thread is that you guys are using Jira far
>>>> too much for trivial stuff. It's a waste of time and resources to go
>>>> through all the Jira steps for simple changes; instead, you should
>>>> learn
>>>> to write descriptive commit log messages and use Jira only for tracking
>>>> large changes or bugs that can't be addressed immediately.
>>>>
>>>>
>>>> As it stands, you're proposing to change an open development process
>>>> into a bureaucratic nightmare. Please don't.
>>>>
>>>> -- Brane
>
>
Re: Jira Process
Posted by Atri Sharma <at...@gmail.com>.
I totally agree on this one.
In PostgreSQL, every committer's major changes are normally reviewed by
somebody else before the committer pushes the patch. However, for trivial
patches, committer normally puts post on developer list stating his changes
and gives a timeline by which he/she will commit patch and objections need
to come before that. Giving a day for such patches should be fine, IMO.
On Mon, Jul 27, 2015 at 12:15 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > I second.
> >
> > It's up to the community to go CTR or RTC but former has a way more
> > flexibility and way speedier. Esp. considering that Ignite has great and
> > functional CI in place. We are trying to get CTR running in Bigtop, but
> > getting blocked by comprehensive CI being not ready yet.
> >
>
> The process in Ignite is that all committers work in separate branches.
> Committers are free to commit into their branch as often as required.
> However, the process that I prefer is that a review by another committer
> must happen before a final merge to the master takes place.
>
> In my experience, I have seen the simplest of the commits break builds or
> make wrong assumptions.
>
>
> > Please consider the consequences of the decision you're about to make.
> >
>
> I was hoping to arrive to a decision as a result of this discussion.
>
>
> >
> > Cos
> >
> > On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <br...@apache.org>
> wrote:
> > >On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> > >> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org>
> > >wrote:
> > >>
> > >>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> > >>>> Igniters,
> > >>>>
> > >>>> I believe several very valid points have been made on the general@
> > >list
> > >>>> about our Jira handling, and how we should improve our Jira
> > >process.
> > >>>>
> > >>>> I have tried to outline the Jira Process we should follow on our
> > >Wiki:
> > >>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> > >>>>
> > >>>> Please review and provide comments. Let's try to finalize it within
> > >the
> > >>>> next couple of days.
> > >>> This describes a commit-then-review process. This is absolutely not
> > >what
> > >>> you want. There is no need to ask for patch review before
> > >committing;
> > >>> this should happen after commit. The only case where the ticket
> > >review
> > >>> stage makes sense is when someone who is not a committer is writing
> > >the
> > >>> patch; or when the committer feels she needs extra eyes on the
> > >change.
> > >>>
> > >> Brane, I am not sure if I understood you correctly. The process that
> > >I
> > >> would like to see in Ignite is that absolutely every ticket undergoes
> > >a
> > >> review process before it gets merged to the main master branch,
> > >regardless
> > >> of whether it is done by a committer or not.
> > >>
> > >> Are you suggesting that the review process for committers should be
> > >> optional?
> > >
> > >Yes of course. The default process for making changes should be:
> > >commit,
> > >then review (CTR). This means that any committer can make any change
> > >without asking for a review first, and other committers review the
> > >changes after the commit.
> > >
> > >What you're proposing is the review, then commit (RTC) process, which
> > >a)
> > >implies that you don't trust committers even for trivial changes, b)
> > >slows down development and c) IMO is contrary to the spirit of open
> > >source. A committer should know when a change really needs review
> > >before
> > >committing, otherwise you shouldn't have made her a committer in the
> > >first place.
> > >
> > >My point in that discussion thread is that you guys are using Jira far
> > >too much for trivial stuff. It's a waste of time and resources to go
> > >through all the Jira steps for simple changes; instead, you should
> > >learn
> > >to write descriptive commit log messages and use Jira only for tracking
> > >large changes or bugs that can't be addressed immediately.
> > >
> > >
> > >As it stands, you're proposing to change an open development process
> > >into a bureaucratic nightmare. Please don't.
> > >
> > >-- Brane
> >
>
--
Regards,
Atri
*l'apprenant*
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 08:45, Dmitriy Setrakyan wrote:
> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
>> I second.
>>
>> It's up to the community to go CTR or RTC but former has a way more
>> flexibility and way speedier. Esp. considering that Ignite has great and
>> functional CI in place. We are trying to get CTR running in Bigtop, but
>> getting blocked by comprehensive CI being not ready yet.
>>
> The process in Ignite is that all committers work in separate branches.
> Committers are free to commit into their branch as often as required.
> However, the process that I prefer is that a review by another committer
> must happen before a final merge to the master takes place.
>
> In my experience, I have seen the simplest of the commits break builds or
> make wrong assumptions.
You do not fix this by implementing a heavyweight process. If merges to
master regularly break builds, teach the person involved to run tests
locally before merging (preferably after syncing their dev branch from
master). A committer is supposed to be competent, after all.
-- Brane
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I second.
>
> It's up to the community to go CTR or RTC but former has a way more
> flexibility and way speedier. Esp. considering that Ignite has great and
> functional CI in place. We are trying to get CTR running in Bigtop, but
> getting blocked by comprehensive CI being not ready yet.
>
The process in Ignite is that all committers work in separate branches.
Committers are free to commit into their branch as often as required.
However, the process that I prefer is that a review by another committer
must happen before a final merge to the master takes place.
In my experience, I have seen the simplest of the commits break builds or
make wrong assumptions.
> Please consider the consequences of the decision you're about to make.
>
I was hoping to arrive to a decision as a result of this discussion.
>
> Cos
>
> On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <br...@apache.org> wrote:
> >On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> >> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org>
> >wrote:
> >>
> >>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> >>>> Igniters,
> >>>>
> >>>> I believe several very valid points have been made on the general@
> >list
> >>>> about our Jira handling, and how we should improve our Jira
> >process.
> >>>>
> >>>> I have tried to outline the Jira Process we should follow on our
> >Wiki:
> >>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> >>>>
> >>>> Please review and provide comments. Let's try to finalize it within
> >the
> >>>> next couple of days.
> >>> This describes a commit-then-review process. This is absolutely not
> >what
> >>> you want. There is no need to ask for patch review before
> >committing;
> >>> this should happen after commit. The only case where the ticket
> >review
> >>> stage makes sense is when someone who is not a committer is writing
> >the
> >>> patch; or when the committer feels she needs extra eyes on the
> >change.
> >>>
> >> Brane, I am not sure if I understood you correctly. The process that
> >I
> >> would like to see in Ignite is that absolutely every ticket undergoes
> >a
> >> review process before it gets merged to the main master branch,
> >regardless
> >> of whether it is done by a committer or not.
> >>
> >> Are you suggesting that the review process for committers should be
> >> optional?
> >
> >Yes of course. The default process for making changes should be:
> >commit,
> >then review (CTR). This means that any committer can make any change
> >without asking for a review first, and other committers review the
> >changes after the commit.
> >
> >What you're proposing is the review, then commit (RTC) process, which
> >a)
> >implies that you don't trust committers even for trivial changes, b)
> >slows down development and c) IMO is contrary to the spirit of open
> >source. A committer should know when a change really needs review
> >before
> >committing, otherwise you shouldn't have made her a committer in the
> >first place.
> >
> >My point in that discussion thread is that you guys are using Jira far
> >too much for trivial stuff. It's a waste of time and resources to go
> >through all the Jira steps for simple changes; instead, you should
> >learn
> >to write descriptive commit log messages and use Jira only for tracking
> >large changes or bugs that can't be addressed immediately.
> >
> >
> >As it stands, you're proposing to change an open development process
> >into a bureaucratic nightmare. Please don't.
> >
> >-- Brane
>
Re: Jira Process
Posted by Konstantin Boudnik <co...@apache.org>.
I second.
It's up to the community to go CTR or RTC but former has a way more flexibility and way speedier. Esp. considering that Ignite has great and functional CI in place. We are trying to get CTR running in Bigtop, but getting blocked by comprehensive CI being not ready yet.
Please consider the consequences of the decision you're about to make.
Cos
On July 26, 2015 11:13:40 PM PDT, "Branko Čibej" <br...@apache.org> wrote:
>On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org>
>wrote:
>>
>>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
>>>> Igniters,
>>>>
>>>> I believe several very valid points have been made on the general@
>list
>>>> about our Jira handling, and how we should improve our Jira
>process.
>>>>
>>>> I have tried to outline the Jira Process we should follow on our
>Wiki:
>>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>>>>
>>>> Please review and provide comments. Let's try to finalize it within
>the
>>>> next couple of days.
>>> This describes a commit-then-review process. This is absolutely not
>what
>>> you want. There is no need to ask for patch review before
>committing;
>>> this should happen after commit. The only case where the ticket
>review
>>> stage makes sense is when someone who is not a committer is writing
>the
>>> patch; or when the committer feels she needs extra eyes on the
>change.
>>>
>> Brane, I am not sure if I understood you correctly. The process that
>I
>> would like to see in Ignite is that absolutely every ticket undergoes
>a
>> review process before it gets merged to the main master branch,
>regardless
>> of whether it is done by a committer or not.
>>
>> Are you suggesting that the review process for committers should be
>> optional?
>
>Yes of course. The default process for making changes should be:
>commit,
>then review (CTR). This means that any committer can make any change
>without asking for a review first, and other committers review the
>changes after the commit.
>
>What you're proposing is the review, then commit (RTC) process, which
>a)
>implies that you don't trust committers even for trivial changes, b)
>slows down development and c) IMO is contrary to the spirit of open
>source. A committer should know when a change really needs review
>before
>committing, otherwise you shouldn't have made her a committer in the
>first place.
>
>My point in that discussion thread is that you guys are using Jira far
>too much for trivial stuff. It's a waste of time and resources to go
>through all the Jira steps for simple changes; instead, you should
>learn
>to write descriptive commit log messages and use Jira only for tracking
>large changes or bugs that can't be addressed immediately.
>
>
>As it stands, you're proposing to change an open development process
>into a bureaucratic nightmare. Please don't.
>
>-- Brane
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org> wrote:
>
>> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
>>> Igniters,
>>>
>>> I believe several very valid points have been made on the general@ list
>>> about our Jira handling, and how we should improve our Jira process.
>>>
>>> I have tried to outline the Jira Process we should follow on our Wiki:
>>> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>>>
>>> Please review and provide comments. Let's try to finalize it within the
>>> next couple of days.
>> This describes a commit-then-review process. This is absolutely not what
>> you want. There is no need to ask for patch review before committing;
>> this should happen after commit. The only case where the ticket review
>> stage makes sense is when someone who is not a committer is writing the
>> patch; or when the committer feels she needs extra eyes on the change.
>>
> Brane, I am not sure if I understood you correctly. The process that I
> would like to see in Ignite is that absolutely every ticket undergoes a
> review process before it gets merged to the main master branch, regardless
> of whether it is done by a committer or not.
>
> Are you suggesting that the review process for committers should be
> optional?
Yes of course. The default process for making changes should be: commit,
then review (CTR). This means that any committer can make any change
without asking for a review first, and other committers review the
changes after the commit.
What you're proposing is the review, then commit (RTC) process, which a)
implies that you don't trust committers even for trivial changes, b)
slows down development and c) IMO is contrary to the spirit of open
source. A committer should know when a change really needs review before
committing, otherwise you shouldn't have made her a committer in the
first place.
My point in that discussion thread is that you guys are using Jira far
too much for trivial stuff. It's a waste of time and resources to go
through all the Jira steps for simple changes; instead, you should learn
to write descriptive commit log messages and use Jira only for tracking
large changes or bugs that can't be addressed immediately.
As it stands, you're proposing to change an open development process
into a bureaucratic nightmare. Please don't.
-- Brane
Re: Jira Process
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <br...@apache.org> wrote:
> On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> > Igniters,
> >
> > I believe several very valid points have been made on the general@ list
> > about our Jira handling, and how we should improve our Jira process.
> >
> > I have tried to outline the Jira Process we should follow on our Wiki:
> > https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
> >
> > Please review and provide comments. Let's try to finalize it within the
> > next couple of days.
>
> This describes a commit-then-review process. This is absolutely not what
> you want. There is no need to ask for patch review before committing;
> this should happen after commit. The only case where the ticket review
> stage makes sense is when someone who is not a committer is writing the
> patch; or when the committer feels she needs extra eyes on the change.
>
Brane, I am not sure if I understood you correctly. The process that I
would like to see in Ignite is that absolutely every ticket undergoes a
review process before it gets merged to the main master branch, regardless
of whether it is done by a committer or not.
Are you suggesting that the review process for committers should be
optional?
>
> -- Brane
> ****
>
Re: Jira Process
Posted by Branko Čibej <br...@apache.org>.
On 27.07.2015 07:04, Dmitriy Setrakyan wrote:
> Igniters,
>
> I believe several very valid points have been made on the general@ list
> about our Jira handling, and how we should improve our Jira process.
>
> I have tried to outline the Jira Process we should follow on our Wiki:
> https://cwiki.apache.org/confluence/display/IGNITE/Jira+Process
>
> Please review and provide comments. Let's try to finalize it within the
> next couple of days.
This describes a commit-then-review process. This is absolutely not what
you want. There is no need to ask for patch review before committing;
this should happen after commit. The only case where the ticket review
stage makes sense is when someone who is not a committer is writing the
patch; or when the committer feels she needs extra eyes on the change.
-- Brane
****