How to interpret the commit-then-review (CTR) mode for trunk?

[Mark Martinec <Ma...@ijs.si>]

Regarding [Bug 6426], [Bug 6544], and some other similar ones,
suggested to be closed by Darxus. These are problem reports
(often opened by me) to document some new feature or some
bug fix requiring a more extensive fix. As the trunk is in
the CTR mode, the changes were already commited to trunk,
have been tested at least by me, and are in productiion use by
those sites which have chosen to run trunk code in production
(because release cycle have been so slow lately and the trunk
has actually been more reliable/stable than 3.3 or 3.2).

These problem reports are mainly opened for documenting the
change, and for soliciting any violent opposing votes :),
so keeping them open for a while is probably a good way
to let developers be made aware of new features.

In C-T-R mode we eventually arrive to the R (review) phase.

We could adapt a more practical stance, and consider the
final vote for some release version to imply a review/approval
of any changes that have been commited so far - assuming the
changes were documented and their tickets open for some
sensible time period. We have probably followed this approach
occasionally in the past. I'm fine with this approach, I just
don't think it follows the published procedure to the letter.

So, taking [Bug 6426] and [Bug 6544] as examples, what is
a sentiment about such? Just close after the change has been
commited to trunk for some time, or should we follow a voting
procedure for each open problem report?

  Mark

Re: How to interpret the commit-then-review (CTR) mode for trunk?

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

What he said.  +1

On 23/05/2011 6:02 PM, Michael Parker wrote:
>
> On May 23, 2011, at 4:32 PM, Mark Martinec wrote:
>
>> So, taking [Bug 6426] and [Bug 6544] as examples, what is
>> a sentiment about such? Just close after the change has been
>> commited to trunk for some time, or should we follow a voting
>> procedure for each open problem report?
>>
>
> First off, you're very good about opening bugs for large changes, thank you.  I actually think that some changes are small enough that they don't even need a bug, but don't mind them because it can be a handy place to review what is happening in the tree.
>
> When a bug is opened for a change and the the change is committed and then the bug closed that generates at least 3 different email events about the change.  IMO this is plenty of visibility to a change and plenty of opportunity for someone to stand up and say "Hey I've got an issue" or "Hey did you think about doing it this way."
>
> So, there is no need to keep these bugs open, go ahead and close them and be done.
>
> Now, if it's a change that you would like to see backported that is another matter, but I think we all know that use case.
>
> I would also take this opportunity to argue that we backport far too many changes.  I think that one of the reasons that newer releases aren't as forthcoming is because all the new stuff is getting backported to the older releases so there is no real need. Personally I would like to limit backporting to just critical and security type issues and keep trunk moving forward, and of course producing more releases.
>
> Ok, just my $.02.
>
> Michael
>

Re: How to interpret the commit-then-review (CTR) mode for trunk?

[Michael Parker <pa...@pobox.com>]

On May 23, 2011, at 4:32 PM, Mark Martinec wrote:

> So, taking [Bug 6426] and [Bug 6544] as examples, what is
> a sentiment about such? Just close after the change has been
> commited to trunk for some time, or should we follow a voting
> procedure for each open problem report?
> 

First off, you're very good about opening bugs for large changes, thank you.  I actually think that some changes are small enough that they don't even need a bug, but don't mind them because it can be a handy place to review what is happening in the tree.

When a bug is opened for a change and the the change is committed and then the bug closed that generates at least 3 different email events about the change.  IMO this is plenty of visibility to a change and plenty of opportunity for someone to stand up and say "Hey I've got an issue" or "Hey did you think about doing it this way."

So, there is no need to keep these bugs open, go ahead and close them and be done.

Now, if it's a change that you would like to see backported that is another matter, but I think we all know that use case.

I would also take this opportunity to argue that we backport far too many changes.  I think that one of the reasons that newer releases aren't as forthcoming is because all the new stuff is getting backported to the older releases so there is no real need. Personally I would like to limit backporting to just critical and security type issues and keep trunk moving forward, and of course producing more releases.

Ok, just my $.02.

Michael

Re: How to interpret the commit-then-review (CTR) mode for trunk?

[da...@chaosreigns.com]

> So, taking [Bug 6426] and [Bug 6544] as examples, what is
> a sentiment about such? Just close after the change has been
> commited to trunk for some time, or should we follow a voting
> procedure for each open problem report?

Documentation is here:
http://wiki.apache.org/spamassassin/DevelopmentMode

It links to:
http://www.apache.org/foundation/glossary.html#CommitThenReview

Which says:

"(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes
which permits developers to make changes at will, with the possibility of
being retroactively vetoed. C-T-R is an application of decision making
through lazy consensus. The C-T-R model is useful in rapid-prototyping
environments, but because of the lack of mandatory review it may permit
more bugs through than the R-T-C alternative. Compare , and see the
description of the voting process."

Which I interpret to mean that you should close such bugs immediately.

It doesn't actually say review is necessary anywhere.

-- 
"Let's just say that if complete and utter chaos was lightning, then
he'd be the sort to stand on a hilltop in a thunderstorm wearing wet
copper armour and shouting 'All gods are bastards'." - The Color of Magic
http://www.ChaosReigns.com