Committer questions.  I accidentally checked in some changes to HBase
trunk with the Phabricator checkin format.  I used svn propedit to correct
the log comments, so everything should look correct.  However, this raised
a couple questions about committing code to HBase.

1.  I know the required format is "HBASE-##### Title".  Is anything else
allowed?  Would including Phabricator comment mess up existing scripts?
I'm assuming people are running something just slightly more complicated
than "svn log|grep ^HBASE".
  2.  Is there a reason why our CHANGES.txt isn't automated?  This is
kinda a pain to keep updated, especially for something that we could just
run "svn log|grep ^HBASE" on right before release.  I know that HIVE
changelog is auto-generated.  I'm assuming most other projects do this as
well.

On Tue, Nov 1, 2011 at 3:20 PM, Nicolas Spiegelberg <[EMAIL PROTECTED]> wrote:
> Committer questions.  I accidentally checked in some changes to HBase
> trunk with the Phabricator checkin format.  I used svn propedit to correct
> the log comments, so everything should look correct.  However, this raised
> a couple questions about committing code to HBase.
>
> 1.  I know the required format is "HBASE-##### Title".  Is anything else
> allowed?  Would including Phabricator comment mess up existing scripts?
> I'm assuming people are running something just slightly more complicated
> than "svn log|grep ^HBASE".

IIRC, we just picked up the hadoop convention.

I used to be of the school where commit message was fat describing all
that changed but seems like fashion now is to have that up in the
JIRA.  I kinda liked having the big commit messages; made the commit
log more interesting reading.

>  2.  Is there a reason why our CHANGES.txt isn't automated?  This is
> kinda a pain to keep updated, especially for something that we could just
> run "svn log|grep ^HBASE" on right before release.  I know that HIVE
> changelog is auto-generated.  I'm assuming most other projects do this as
> well.
>

We should just auto-generate it.  JIRA can do it for us.  Its a PITA
trying to keep it up and its always going to have holes in it.  I
suggest we move to auto-generated in TRUNK.

St.Ack

> From: Stack <[EMAIL PROTECTED]>

> I used to be of the school where commit message was fat describing all
> that changed but seems like fashion now is to have that up in the
> JIRA.  I kinda liked having the big commit messages; made the commit
> log more interesting reading.
Having the below at the top of the message all on one line facilitates grepping:

   HBASE-xxx <title>
 
Beyond that, I've perused the commit log on 0.89-fb and certainly wouldn't mind if similar Summary and Test Plan conventions made it upstream. I spend a lot of time browsing commit logs these days, having that information can put the diff in better context.

> We should just auto-generate it.  JIRA can do it for us.  Its a PITA
> trying to keep it up and its always going to have holes in it.  I
> suggest we move to auto-generated in TRUNK.
+1

Best regards,
   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
----- Original Message -----
> From: Stack <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc:
> Sent: Tuesday, November 1, 2011 3:34 PM
> Subject: Re: Commit Log format
>
> On Tue, Nov 1, 2011 at 3:20 PM, Nicolas Spiegelberg <[EMAIL PROTECTED]>
> wrote:
>>  Committer questions.  I accidentally checked in some changes to HBase
>>  trunk with the Phabricator checkin format.  I used svn propedit to correct
>>  the log comments, so everything should look correct.  However, this raised
>>  a couple questions about committing code to HBase.
>>
>>  1.  I know the required format is "HBASE-##### Title".  Is
> anything else
>>  allowed?  Would including Phabricator comment mess up existing scripts?
>>  I'm assuming people are running something just slightly more
> complicated
>>  than "svn log|grep ^HBASE".
>
> IIRC, we just picked up the hadoop convention.
>
> I used to be of the school where commit message was fat describing all
> that changed but seems like fashion now is to have that up in the
> JIRA.  I kinda liked having the big commit messages; made the commit
> log more interesting reading.
>
>>   2.  Is there a reason why our CHANGES.txt isn't automated?  This is
>>  kinda a pain to keep updated, especially for something that we could just
>>  run "svn log|grep ^HBASE" on right before release.  I know that
> HIVE
>>  changelog is auto-generated.  I'm assuming most other projects do this
> as
>>  well.
>>
>
> We should just auto-generate it.  JIRA can do it for us.  Its a PITA
> trying to keep it up and its always going to have holes in it.  I
> suggest we move to auto-generated in TRUNK.
>
> St.Ack
>

To kick a dead horse, coupling the code diff with the CHANGES.txt
alteration is also a massive PITA because its much harder to run 'git
cherry-pick' across branches with it.  It's far easier to directly port a
change from 92 to trunk to 89-fb if I don't have that pesky little file in
the way.

On 11/1/11 3:34 PM, "Stack" <[EMAIL PROTECTED]> wrote:

>We should just auto-generate it.  JIRA can do it for us.  Its a PITA
>trying to keep it up and its always going to have holes in it.  I
>suggest we move to auto-generated in TRUNK.
>
>St.Ack

+1 both on more descriptive commit messages and on kiling off CHANGES.txt.

-Todd

On Tue, Nov 1, 2011 at 4:13 PM, Nicolas Spiegelberg <[EMAIL PROTECTED]> wrote:
> To kick a dead horse, coupling the code diff with the CHANGES.txt
> alteration is also a massive PITA because its much harder to run 'git
> cherry-pick' across branches with it.  It's far easier to directly port a
> change from 92 to trunk to 89-fb if I don't have that pesky little file in
> the way.
>
> On 11/1/11 3:34 PM, "Stack" <[EMAIL PROTECTED]> wrote:
>
>>We should just auto-generate it.  JIRA can do it for us.  Its a PITA
>>trying to keep it up and its always going to have holes in it.  I
>>suggest we move to auto-generated in TRUNK.
>>
>>St.Ack
>
>

--
Todd Lipcon
Software Engineer, Cloudera

I've been marching through the CHANGES.txt file for 0.92 -- and have found
some bugs in the jira and in the CHANGES.txt file itself (will submit patch
to fix these).

If we are going to depend on the jira to auto generate, it is becomes
really important to update fix version on the jira if we are going to use
the JIRA to autogenerate it!  I've been going through an updated the empty
ones I've noticed.

This brings up another question -- as I've been going I noticed some are
marked 0.90.5 but also have been committed to the 0.92/trunk branches.  If
a patch committed to multiple branches such as trunk/0.90 branches, my
opinion is that it the fix version include both 0.90.5, 0.92.
 Alternately, we could assume that any 0.90.5+ is in 0.92.

Do you all have a preference?

Jon.
On Tue, Nov 1, 2011 at 4:58 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> +1 both on more descriptive commit messages and on kiling off CHANGES.txt.
>
> -Todd
>
> On Tue, Nov 1, 2011 at 4:13 PM, Nicolas Spiegelberg <[EMAIL PROTECTED]>
> wrote:
> > To kick a dead horse, coupling the code diff with the CHANGES.txt
> > alteration is also a massive PITA because its much harder to run 'git
> > cherry-pick' across branches with it.  It's far easier to directly port a
> > change from 92 to trunk to 89-fb if I don't have that pesky little file
> in
> > the way.
> >
> > On 11/1/11 3:34 PM, "Stack" <[EMAIL PROTECTED]> wrote:
> >
> >>We should just auto-generate it.  JIRA can do it for us.  Its a PITA
> >>trying to keep it up and its always going to have holes in it.  I
> >>suggest we move to auto-generated in TRUNK.
> >>
> >>St.Ack
> >
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

On Wed, Nov 16, 2011 at 8:18 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> I've been marching through the CHANGES.txt file for 0.92 -- and have found
> some bugs in the jira and in the CHANGES.txt file itself (will submit patch
> to fix these).
>

Thanks boss.

> If we are going to depend on the jira to auto generate, it is becomes
> really important to update fix version on the jira if we are going to use
> the JIRA to autogenerate it!  I've been going through an updated the empty
> ones I've noticed.
>

Agreed and thanks for the fixup.
> This brings up another question -- as I've been going I noticed some are
> marked 0.90.5 but also have been committed to the 0.92/trunk branches.  If
> a patch committed to multiple branches such as trunk/0.90 branches, my
> opinion is that it the fix version include both 0.90.5, 0.92.
>  Alternately, we could assume that any 0.90.5+ is in 0.92.
>

My gut reaction is that we mark in JIRA all the versions the fix will
show up in.   0.90.5 is a little awkward since CHANGES.txt has been
kept-up old-style manual edit but I think that when it comes to
0.90.6, 0.94.0, etc., future versions, lets just mark a fix's
inclusion in the one place only (In JIRA).

Good stuff,
St.Ack