Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Chukwa >> mail # dev >> [DISCUSS] Applying commit-then-review


Copy link to this message
-
Re: [DISCUSS] Applying commit-then-review
On Mon, Sep 13, 2010 at 22:50, Bill Graham <[EMAIL PROTECTED]> wrote:
> I can see advantages to both CTR and RTC. For bugs and even modest
> changes, yes CTR seems fine. Recent examples where I would have
> preferred to do that include:
>
> https://issues.apache.org/jira/browse/CHUKWA-517
> https://issues.apache.org/jira/browse/CHUKWA-518
> https://issues.apache.org/jira/browse/CHUKWA-519
>
> Bigger changes though, especially ones that have an external face on
> them, like the recent REST API features, are good to have more of a
> feedback gathering RTC phase, like these:
>
> https://issues.apache.org/jira/browse/CHUKWA-515
> https://issues.apache.org/jira/browse/CHUKWA-520
>
> A few questions a have though about CTR:
>
> - Bernd, from your initial comments it sounds like in some cases you
> don't even have a JIRA filed with the commit. Is that the case? I've
> always thought that a commit should really have a JIRA just for
> tracking, but I can change that thinking. Can you elaborate on how you
> see JIRA playing into CTR?

Before we had JIRA at the ASF (only bugzilla, which is no fun at all
IMHO), we did CTR without filing issues, of course.
Sometimes, patches where attached on-list.
Today, most projects indeed file a JIRA for everything, to benefit
from fully JIRA-generated release notes etc.

CTR works great with JIRA:
+ Create JIRA issue
+ commit a patch, using the JIRA name ("CHUKWA-1234") in the commit log message
+ JIRA automatically detects and attaches the svn change log to the
issue (see the "subversion commits" tab in JIRA)
(+ iterate with more commits)
+ Close the issue (, reopen etc.)

> - Similarly, it sounds like patches aren't needed with CTR. The
> downside of this is that others can't easily apply the patch to a
> release distribution and rebuild (something I do all the time). I'd
> think if it's worth committing, it's worth having a patch file for
> others to apply. Any thoughts around this?

The svn commit log and the chukwa-commit mailing list give you an easy
way to access patches.

> I generally like the discussion around how to become more agile
> though, since I see many benefits to be had there. I recently skimmed
> some of the CTR discussion on the apache site and thought to myself
> that that sounds different than what we're doing.

Well, with this discussion thread I just meant to spin CTR. If RTC (or
any relaxed derivative thereof) is the way *you* as committers want to
go ahead, I definitively support it.
I don't mean to discrupt any well-established process just for the
sake of disruption.

  Bernd

> On Mon, Sep 13, 2010 at 1:14 PM, Ariel Rabkin <[EMAIL PROTECTED]> wrote:
>>
>> Our methodology is actually some hybrid; something like "wait for
>> potential review", then commit.  Usually I'll commit after a few days
>> if nobody objected or commented.  (I try to say explicitly when I'll
>> time out waiting for comments.)  And most of the patch review is
>> fairly cursory.
>>
>> I agree that the full rigor of RTC is probably unnecessary.  I do like
>> it, however, for bigger changes, particularly those that alter the
>> architecture or user visible feature set.
>>
>> Is it reasonable to say "for bugs, CTR is fine, and only file a JIRA
>> and wait for review if it's going to break something"?
>>
>> --Ari
>>
>> On Mon, Sep 13, 2010 at 12:58 PM, Bernd Fondermann
>> <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > If I understand correctly, Chukwa is following the review-then-commit
>> > (RTC) pattern: Before every commit, a patch gets posted to a JIRA and
>> > only on positive feedback it is committed.
>> > As far as I can see, this is inherited from Hadoop's policies.
>> > However, most projects at the ASF apply commit-then-review (CTR). CTR
>> > has the advantage of being more agile, requiring less work (creating
>> > issue, patch file, attaching it, waiting for feedback etc.) while
>> > providing full oversight:
>> > Every commit is reviewed by other committers after it happened, can be