Jira Process

[dsetrakyan]

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.

[Branko Čibej]

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
****

[dsetrakyan]

On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]> 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
> ****
>

[Branko Čibej]

On 27.07.2015 07:47, Dmitriy Setrakyan wrote:

> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]> 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

[Konstantin Boudnik-2]

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" <[hidden email]> wrote:

>On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]>
>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

[dsetrakyan]

On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <[hidden email]> 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" <[hidden email]> wrote:
> >On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> >> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]>
> >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
>

[Branko Čibej]

On 27.07.2015 08:45, Dmitriy Setrakyan wrote:

> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <[hidden email]> 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

[Atri Sharma]

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 <[hidden email]>
wrote:

> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <[hidden email]>
> 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" <[hidden email]>
> wrote:
> > >On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> > >> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]>
> > >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*

[Branko Čibej]

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 <[hidden email]>
> wrote:
>
>> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <[hidden email]>
>> 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" <[hidden email]>
>> wrote:
>>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
>>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]>
>>>> 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
>
>

[dsetrakyan]

On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <[hidden email]> 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 <
> [hidden email]>
> > wrote:
> >
> >> On Sun, Jul 26, 2015 at 11:31 PM, Konstantin Boudnik <[hidden email]>
> >> 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" <[hidden email]>
> >> wrote:
> >>>> On 27.07.2015 07:47, Dmitriy Setrakyan wrote:
> >>>>> On Sun, Jul 26, 2015 at 10:39 PM, Branko Čibej <[hidden email]>
> >>>> 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
> >
> >
>
>

[Atri Sharma]

On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <[hidden email]> 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.

[Branko Čibej]

On 27.07.2015 09:12, Dmitriy Setrakyan wrote:

> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <[hidden email]> 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

[Branko Čibej]

On 27.07.2015 09:17, Atri Sharma wrote:

> On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
>> On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <[hidden email]> 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

[dsetrakyan]

On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <[hidden email]> 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
>
>

[Atri Sharma]

On Mon, Jul 27, 2015 at 1:03 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <[hidden email]> 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?

[dsetrakyan]

On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]> wrote:

>
> We've all seen problems with bad commits. Bugs happen. If it's
> accidental, live with it. If it's consistent from some person, teach
> said person to do better. There's no reason to go all paranoid over a
> potential occasional bug in a commit.
>
> I mean, it's ridiculous to go all agile with sprints and scrums and CI
> and whatnot, and then block progress because you're afraid to trust your
> fellow developers to not goof off all the time.
>

Just as an observation, I don't think RTC process was slowing down progress
at Ignite as reviews usually happen pretty fast. 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
>
>

[Branko Čibej]

On 27.07.2015 09:33, Dmitriy Setrakyan wrote:

> On Mon, Jul 27, 2015 at 12:26 AM, Branko Čibej <[hidden email]> 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

[Branko Čibej]

On 27.07.2015 09:36, Dmitriy Setrakyan wrote:

> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]> wrote:
>> We've all seen problems with bad commits. Bugs happen. If it's
>> accidental, live with it. If it's consistent from some person, teach
>> said person to do better. There's no reason to go all paranoid over a
>> potential occasional bug in a commit.
>>
>> I mean, it's ridiculous to go all agile with sprints and scrums and CI
>> and whatnot, and then block progress because you're afraid to trust your
>> fellow developers to not goof off all the time.
>>
> Just as an observation, I don't think RTC process was slowing down progress
> at Ignite as reviews usually happen pretty fast.

They do now, when the project is fresh and the majority of active
committers are actually not doing this in their spare time. You need to
think ahead a bit, too.

-- Brane

[Atri Sharma]

On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <[hidden email]> wrote:

> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
> > On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]> wrote:
> >> We've all seen problems with bad commits. Bugs happen. If it's
> >> accidental, live with it. If it's consistent from some person, teach
> >> said person to do better. There's no reason to go all paranoid over a
> >> potential occasional bug in a commit.
> >>
> >> I mean, it's ridiculous to go all agile with sprints and scrums and CI
> >> and whatnot, and then block progress because you're afraid to trust your
> >> fellow developers to not goof off all the time.
> >>
> > Just as an observation, I don't think RTC process was slowing down
> progress
> > at Ignite as reviews usually happen pretty fast.
>
> They do now, when the project is fresh and the majority of active
> committers are actually not doing this in their spare time. You need to
> think ahead a bit, too.
>
>

I do see your point but I think you will agree that a pre message on
developers list is necessary giving time for  potential objections.

[Branko Čibej]

On 27.07.2015 09:43, Atri Sharma wrote:

> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <[hidden email]> wrote:
>
>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote:
>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <[hidden email]> wrote:
>>>> We've all seen problems with bad commits. Bugs happen. If it's
>>>> accidental, live with it. If it's consistent from some person, teach
>>>> said person to do better. There's no reason to go all paranoid over a
>>>> potential occasional bug in a commit.
>>>>
>>>> I mean, it's ridiculous to go all agile with sprints and scrums and CI
>>>> and whatnot, and then block progress because you're afraid to trust your
>>>> fellow developers to not goof off all the time.
>>>>
>>> Just as an observation, I don't think RTC process was slowing down
>> progress
>>> at Ignite as reviews usually happen pretty fast.
>> They do now, when the project is fresh and the majority of active
>> committers are actually not doing this in their spare time. You need to
>> think ahead a bit, too.
>>
>>
> I do see your point but I think you will agree that a pre message on
> developers list is necessary giving time for  potential objections.

The point is that I definitely do not agree with that. Developer receive
commit notifications; that's enough of a nudge to review the commit.

In my experience, prior reviews don't find any more bugs that post
reviews. This assumes two preconditions: a) Design discussions and
decisions are made on the dev@ list before a feature or change is made;
and b) developers request a prior review when they feel it's necessary.
But it should be up to the developer to make that judgement call.

-- Brane