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