Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB