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 think this is a good discussion to have, even if we decide not to
change our process.

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

I like the possibility of being able to commit without making a patch
file and attaching it to a JIRA, so digging into this a bit more...

Looking at "Subversion Commits" tab, let's use Eric's large CHUKWA-444
commit as an example. If he hadn't made a patch file, would there be
an easy way for a Chukwa user to get a patch of the diff from JIRA
(i.e., without having to check out the source and pipe an svn diff
between the revisions to a file)? If so, that would be ideal.
On Tue, Sep 14, 2010 at 3:17 AM, Bernd Fondermann
> 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.