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

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

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.

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
> > discussed, reverted, improved etc. as a 'work in progress'.
> > It is best practice in CTR-mode to selectively use RTC, e.g. for big
> > patches or for potentially delicate commits.
> >
> > I think Chukwa would profit from changing to CTR, so I'd like to know
> > what you think about it.
> >
> > Thanks,
> >
> >   Bernd
> >
>
>
>
> --
> Ari Rabkin [EMAIL PROTECTED]
> UC Berkeley Computer Science Department