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 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
<[EMAIL PROTECTED]> wrote:
> 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.
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