You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2012/11/07 16:26:29 UTC
Re: Rant: Request for better commit messages
Should we add a line to this commit message, where people can mark whether
this patch should be considered for the next bugfix release? Or is that all
handled/tracked through JIRA or some other means? I just thought it would
be nice for the guy maintaining a release to be able to eventually pull in
stuff based on the commit messages. It also allows the committers to give
some sort of indication that commit X is important and needs to go into the
bugfix.
For now I'm just adding "Bugfix-for: 4.0" to my commits.
On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <sh...@gmail.com>wrote:
> Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
>
> set it up by running the following from your incubator-cloudstack dir:
>
> 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg'
>
> Developers can also optionally commit different prepare-commit-msg
> scripts for each branch, and the link will point to the one you're on.
>
> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
> wrote:
> >
> > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> >
> >> I'm by no means a git guru, but in searching around it didn't seem like
> >> there was a way to enforce the application of hooks from the repo side.
> >> I'm not sure we'd want to anyway. I was just going to commit the file
> and
> >> then add instructions on the wiki for people to add it in their local
> repo
> >> config.
> >
> > I think that's fine. Instead of hooks what people can do is add a commit
> template to their local git configuration.
> > http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> >
> > Checkout commit.template, add following to your ~/.gitconfig:
> > [commit]
> > template = ~/.gitmessage
> >
> > And create a ~/.gitmessage like:
> > #Header: one line explaination
> > #
> > #Body of commit message explaining things in more detail, possibly
> giving some
> > #background about the issue being fixed, etc. Maybe use bullets:
> > # - Write in present tense
> > # - Keep text width of commit message within 80 characters.
> > #
> > #Use more than one paragraphs, that's is fine.
> > #
> > #Reviewed-by: Person or link to review on review.apache.org
> > #Reported-by: whoever-reported-it, if applicable
> > #Signed-off-by: Your Name <yo...@yourhost.com>
> >
> > Now every time one does git commit, she will see this in their editor
> and use this as a reminder to write better commit message.
> > For example my:
> > gitconfig:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > gitmessage:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> >
> > Regards.
> >
> >> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com> wrote:
> >>
> >>>
> >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> >>>
> >>>> Sure thing. A few questions:
> >>>>
> >>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
> >>>> simply "Bug id:"?
> >>>
> >>> I guess as there are already several commits that follow
> CLOUDSTACK-BUGID
> >>> convention, we should continue that.
> >>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
> >>>
> >>>> I'm assuming that if the commit is a bug fix, the
> >>>> fix will already be described in the summary and detail of the commit.
> >>>> Or are we looking for something else here other than a description? I
> >>>> could just see this being redundant, but perhaps I don't understand
> >>>> what's being asked for on that line. Should id describe the bug itself
> >>>> in one line, rather than the bug fix?
> >>>
> >>> Whatever makes sense, I usually write what that commit does in one
> line.
> >>>
> >>>>
> >>>> I'm also assuming it's ok to add the "Signed-off-by:" to the message.
> >>>> I realize that some people will have their own configs that already do
> >>>> this, or be used to using -s to auto-add it to the message, but
> >>>> judging by the logs it seems that the majority don't. So hopefully
> >>>> this doesn't upset anyone horribly :-) They can always change their
> >>>> copy since the hook will need to be manually installed.
> >>>
> >>> I've just put up bunch of guidelines on the wiki, let's take whatever
> >>> seems good and follow whatever makes sense.
> >>> My whole intension was to bring up the issue that a short commit
> message
> >>> makes it hard for folks to follow commits.
> >>>
> >>>> Attached is an example commit message generated by the hook so far.
> >>>
> >>> Cool, I guess you would have to contact someone from ASF infra to set
> this
> >>> up.
> >>>
> >>>> I
> >>>> left in the default comment message as well, simply because it
> >>>> includes a list of what's modified,etc for reference when typing up
> >>>> the notes.
> >>>
> >>> --
> >>> Rohit
> >>>
> >>>>
> >>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <ro...@citrix.com>
> >>> wrote:
> >>>>>
> >>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> >>>>>
> >>>>> Pl. check and edit as needed.
> >>>>>
> >>>>> One more thing, I checked looks like ASF infra guys have upgraded
> their
> >>> review board.
> >>>>> The bug (
> >>>
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> )
> >>> got fixed so now downloading the diff downloads the actual uploaded git
> >>> formatted patch.
> >>>>>
> >>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Might be cool if we could make/document git hooks for a standard
> >>> message form.
> >>>>>
> >>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> repo
> >>> that would be great.
> >>>>>
> >>>>> Regards.
> >>>>>
> >>>>>>
> >>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <wido@widodh.nl
> >
> >>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> >>>>>>>>
> >>>>>>>> Perhaps we could document this on the wiki, as part of a nascent
> >>> coding
> >>>>>>>> standards policy?
> >>>>>>>
> >>>>>>>
> >>>>>>> I'd say so. We already have a coding convention, it's just a small
> >>> step to
> >>>>>>> add a commit convention.
> >>>>>>>
> >>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> >>>>>>>
> >>>>>>> Wido
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> rohit.yadav@citrix.com
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi folks,
> >>>>>>>>>
> >>>>>>>>> With due respect, I would like to request all the committers and
> >>>>>>>>> contributors to write better commit message. [0]
> >>>>>>>>>
> >>>>>>>>> For example, a good commit message:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> >>>>>>>>>
> >>>>>>>>> A good commit message subject should have something like this
> with
> >>> 80
> >>>>>>>>> chars width:
> >>>>>>>>> <Header line>: <short log description>
> >>>>>>>>> <blank line>
> >>>>>>>>> <body of commit message, explain things why, what, how, etc.
> giving
> >>>>>>>>> background>
> >>>>>>>>> <bulleted points help>
> >>>>>>>>> <blank line>
> >>>>>>>>> <Reported-by: if it's a bug>
> >>>>>>>>> <Reviewed-by: if it was reviewed>
> >>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> >>>>>>>>>
> >>>>>>>>> This is what we follow on
> >>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are crazy
> >>> about
> >>>>>>>>> commits and patches, they just don't accept junk
> >>>>>>>>> messages, even if code is fine. You may check, there is no or few
> >>>>>>>>> reverts.
> >>>>>>>>>
> >>>>>>>>> When something breaks, I check all last commits and do a git log
> -p
> >>>>>>>>> <file>
> >>>>>>>>> to go through recent changes to a file, in case I think something
> >>> broke I
> >>>>>>>>> like to identify the changes that may have caused it instead of
> >>> fixing it
> >>>>>>>>> which may introduce further problems. I use tig and zsh to
> regularly
> >>>>>>>>> follow
> >>>>>>>>> commits and read commit messages.
> >>>>>>>>>
> >>>>>>>>> Also, please fix your editors and follow coding conventions.
> >>>>>>>>>
> >>>>>>>>> [0] https://github.com/torvalds/subsurface/blob/master/README(at
> >>> the
> >>>>>>>>> end)
> >>>>>>>>>
> >>>>>>>>> Regards.
> >>>>>>>>> PS. I had to email about it as we're uncool with our git commit
> >>> habits,
> >>>>>>>>> we
> >>>>>>>>> are doing triple or quadruple reverts, we need to fix our habits.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>> <examplecommitmsg.txt>
> >>>
> >>>
> >
>
Re: Rant: Request for better commit messages
Posted by John Burwell <jb...@basho.com>.
Marcus,
To me, it feels like you are hitting on the difference in audience between a commit message and a ticket. A commit message describes a technical scope, impact, and reasoning of a particular revision in the repository which is geared, primarily, towards other developers to understand the evolution of the codebase. On the other hand, a ticket describes a problem or enhancement, and tracks its progress towards resolution and release which is geared towards the entire community. Finally, for larger enhancements, it is possible that a ticket would be associated with multiple commits.
I agree that we need to be capturing both types of information, but I am proposing that we capture it separately.
-John
On Nov 7, 2012, at 2:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> That's great, I'm fine with that if I need to create a bug for everything
> that I know needs to be fixed in the 4.0 branch for example. The
> header/tag in the commit message may not be something we end up officially
> relying on by any means, but would help me as someone who perhaps maintains
> a specific feature to take a quick look at the logs in master and branch X
> and make sure that everything I thought should be committed ended up in the
> branch, or at least provides me a way to audit. I suppose that's a personal
> thing so I'll just go forward doing that, but it brought up the question as
> to who else might be able to use it or what the official way to tell the
> maintainer of a branch that something needs to be considered for inclusion.
>
> It seems like several things were missed at different points when 4.0 was
> getting cleaned up, and I don't know if that was due to not following
> procedure or a lack of procedure.
>
>
> On Wed, Nov 7, 2012 at 11:31 AM, John Burwell <jb...@basho.com> wrote:
>
>> Marcus,
>>
>> To my mind, it does not seem appropriate for developers to be making
>> release decisions at commit time. Instead, it feels more appropriate to me
>> that these decisions are captured in a ticket that is referenced from the
>> commit message. This separation allows the PMO/release management
>> team/community to determine release contents based on the results of review
>> (via Review Board) and testing. If you feel your change is a high priority
>> and should be in the next release, you would capture that in the ticket.
>> The PMO/release management team/community can then review that decision
>> and comment/adjust as necessary. A commit message does not permit this
>> type of collaboration. This separation also seems make the creation of
>> release notes more straightforward as well.
>>
>> Thanks,
>> -John
>>
>> On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com> wrote:
>>
>>> Really I just want to make sure that a commit I make that I know needs to
>>> be pushed into the next 4.0 bugfix release gets there. Since someone else
>>> is in charge of maintaining 4.0 and merging bug fixes, I can't do it
>>> myself, and I'm not really sure how it works now. For example, does that
>>> maintainer look through a JIRA report and only merge bugfixes listed
>> there?
>>>
>>>
>>> On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <ro...@citrix.com>
>> wrote:
>>>
>>>> I'm not sure how (cherry picking, pull based on commit message) this
>> will
>>>> work, but it's good idea to mark the commit with some tag with say
>> branch
>>>> so we always commit on master?
>>>> (Bugfix-for or Branch: <branches> )
>>>> Branch: 4.0, master #(comma separated branch names).
>>>> Bug-id: CLOUDSTACK-xxx
>>>>
>>>> This may be ambiguous, says some developer did not know if some commit
>>>> would apply for some branch? Another issue is to encourage everyone of
>> us
>>>> to use this convention.
>>>> If we could solve it, that would be great.
>>>>
>>>> ________________________________________
>>>> From: Marcus Sorensen [shadowsor@gmail.com]
>>>> Sent: Wednesday, November 07, 2012 8:56 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: Rant: Request for better commit messages
>>>>
>>>> Should we add a line to this commit message, where people can mark
>> whether
>>>> this patch should be considered for the next bugfix release? Or is that
>> all
>>>> handled/tracked through JIRA or some other means? I just thought it
>> would
>>>> be nice for the guy maintaining a release to be able to eventually pull
>> in
>>>> stuff based on the commit messages. It also allows the committers to
>> give
>>>> some sort of indication that commit X is important and needs to go into
>> the
>>>> bugfix.
>>>>
>>>> For now I'm just adding "Bugfix-for: 4.0" to my commits.
>>>>
>>>>
>>>> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadowsor@gmail.com
>>>>> wrote:
>>>>
>>>>> Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
>>>>>
>>>>> set it up by running the following from your incubator-cloudstack dir:
>>>>>
>>>>> 'ln -s ../../tools/git/prepare-commit-msg
>> .git/hooks/prepare-commit-msg'
>>>>>
>>>>> Developers can also optionally commit different prepare-commit-msg
>>>>> scripts for each branch, and the link will point to the one you're on.
>>>>>
>>>>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
>>>>> wrote:
>>>>>>
>>>>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> I'm by no means a git guru, but in searching around it didn't seem
>>>> like
>>>>>>> there was a way to enforce the application of hooks from the repo
>>>> side.
>>>>>>> I'm not sure we'd want to anyway. I was just going to commit the file
>>>>> and
>>>>>>> then add instructions on the wiki for people to add it in their local
>>>>> repo
>>>>>>> config.
>>>>>>
>>>>>> I think that's fine. Instead of hooks what people can do is add a
>>>> commit
>>>>> template to their local git configuration.
>>>>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
>>>>>>
>>>>>> Checkout commit.template, add following to your ~/.gitconfig:
>>>>>> [commit]
>>>>>> template = ~/.gitmessage
>>>>>>
>>>>>> And create a ~/.gitmessage like:
>>>>>> #Header: one line explaination
>>>>>> #
>>>>>> #Body of commit message explaining things in more detail, possibly
>>>>> giving some
>>>>>> #background about the issue being fixed, etc. Maybe use bullets:
>>>>>> # - Write in present tense
>>>>>> # - Keep text width of commit message within 80 characters.
>>>>>> #
>>>>>> #Use more than one paragraphs, that's is fine.
>>>>>> #
>>>>>> #Reviewed-by: Person or link to review on review.apache.org
>>>>>> #Reported-by: whoever-reported-it, if applicable
>>>>>> #Signed-off-by: Your Name <yo...@yourhost.com>
>>>>>>
>>>>>> Now every time one does git commit, she will see this in their editor
>>>>> and use this as a reminder to write better commit message.
>>>>>> For example my:
>>>>>> gitconfig:
>>>>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
>>>>>> gitmessage:
>>>>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> Sure thing. A few questions:
>>>>>>>>>
>>>>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
>>>>>>>>> simply "Bug id:"?
>>>>>>>>
>>>>>>>> I guess as there are already several commits that follow
>>>>> CLOUDSTACK-BUGID
>>>>>>>> convention, we should continue that.
>>>>>>>> Also, there are commits with bug id's of old jira, like CS-16414
>> etc.
>>>>>>>>
>>>>>>>>> I'm assuming that if the commit is a bug fix, the
>>>>>>>>> fix will already be described in the summary and detail of the
>>>> commit.
>>>>>>>>> Or are we looking for something else here other than a description?
>>>> I
>>>>>>>>> could just see this being redundant, but perhaps I don't understand
>>>>>>>>> what's being asked for on that line. Should id describe the bug
>>>> itself
>>>>>>>>> in one line, rather than the bug fix?
>>>>>>>>
>>>>>>>> Whatever makes sense, I usually write what that commit does in one
>>>>> line.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
>>>> message.
>>>>>>>>> I realize that some people will have their own configs that already
>>>> do
>>>>>>>>> this, or be used to using -s to auto-add it to the message, but
>>>>>>>>> judging by the logs it seems that the majority don't. So hopefully
>>>>>>>>> this doesn't upset anyone horribly :-) They can always change their
>>>>>>>>> copy since the hook will need to be manually installed.
>>>>>>>>
>>>>>>>> I've just put up bunch of guidelines on the wiki, let's take
>> whatever
>>>>>>>> seems good and follow whatever makes sense.
>>>>>>>> My whole intension was to bring up the issue that a short commit
>>>>> message
>>>>>>>> makes it hard for folks to follow commits.
>>>>>>>>
>>>>>>>>> Attached is an example commit message generated by the hook so far.
>>>>>>>>
>>>>>>>> Cool, I guess you would have to contact someone from ASF infra to
>> set
>>>>> this
>>>>>>>> up.
>>>>>>>>
>>>>>>>>> I
>>>>>>>>> left in the default comment message as well, simply because it
>>>>>>>>> includes a list of what's modified,etc for reference when typing up
>>>>>>>>> the notes.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rohit
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
>>>> rohit.yadav@citrix.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
>>>>>>>>>>
>>>>>>>>>> Pl. check and edit as needed.
>>>>>>>>>>
>>>>>>>>>> One more thing, I checked looks like ASF infra guys have upgraded
>>>>> their
>>>>>>>> review board.
>>>>>>>>>> The bug (
>>>>>>>>
>>>>>
>>>>
>> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
>>>>> )
>>>>>>>> got fixed so now downloading the diff downloads the actual uploaded
>>>> git
>>>>>>>> formatted patch.
>>>>>>>>>>
>>>>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Might be cool if we could make/document git hooks for a standard
>>>>>>>> message form.
>>>>>>>>>>
>>>>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
>>>>> repo
>>>>>>>> that would be great.
>>>>>>>>>>
>>>>>>>>>> Regards.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
>>>> wido@widodh.nl
>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps we could document this on the wiki, as part of a
>> nascent
>>>>>>>> coding
>>>>>>>>>>>>> standards policy?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'd say so. We already have a coding convention, it's just a
>>>> small
>>>>>>>> step to
>>>>>>>>>>>> add a commit convention.
>>>>>>>>>>>>
>>>>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
>>>>>>>>>>>>
>>>>>>>>>>>> Wido
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
>>>>> rohit.yadav@citrix.com
>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi folks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With due respect, I would like to request all the committers
>>>> and
>>>>>>>>>>>>>> contributors to write better commit message. [0]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For example, a good commit message:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A good commit message subject should have something like this
>>>>> with
>>>>>>>> 80
>>>>>>>>>>>>>> chars width:
>>>>>>>>>>>>>> <Header line>: <short log description>
>>>>>>>>>>>>>> <blank line>
>>>>>>>>>>>>>> <body of commit message, explain things why, what, how, etc.
>>>>> giving
>>>>>>>>>>>>>> background>
>>>>>>>>>>>>>> <bulleted points help>
>>>>>>>>>>>>>> <blank line>
>>>>>>>>>>>>>> <Reported-by: if it's a bug>
>>>>>>>>>>>>>> <Reviewed-by: if it was reviewed>
>>>>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is what we follow on
>>>>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are
>>>> crazy
>>>>>>>> about
>>>>>>>>>>>>>> commits and patches, they just don't accept junk
>>>>>>>>>>>>>> messages, even if code is fine. You may check, there is no or
>>>> few
>>>>>>>>>>>>>> reverts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When something breaks, I check all last commits and do a git
>>>> log
>>>>> -p
>>>>>>>>>>>>>> <file>
>>>>>>>>>>>>>> to go through recent changes to a file, in case I think
>>>> something
>>>>>>>> broke I
>>>>>>>>>>>>>> like to identify the changes that may have caused it instead
>> of
>>>>>>>> fixing it
>>>>>>>>>>>>>> which may introduce further problems. I use tig and zsh to
>>>>> regularly
>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>> commits and read commit messages.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [0]
>>>> https://github.com/torvalds/subsurface/blob/master/README(at
>>>>>>>> the
>>>>>>>>>>>>>> end)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards.
>>>>>>>>>>>>>> PS. I had to email about it as we're uncool with our git
>> commit
>>>>>>>> habits,
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix our
>>>> habits.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> <examplecommitmsg.txt>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: Rant: Request for better commit messages
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Nov 7, 2012 at 5:58 PM, Alex Huang <Al...@citrix.com> wrote:
> We should remember that we didn't have Jira setup until very late into the 4.0 release. There were a lot of things that leaked through because of that.
>
> We should make use of the Jira functionalities.
Absolutely!
> These steps can be performed by everyone.
> - A bug is filed in issues.apache.org/cloudstack. This should target the releases that it is to be fixed in.
> - If the bug needs to be propagated to another release, a subtask is created for that release.
>
> The release manager decides on whether the bug should be put into the release. Upon which he can do the following things.
> - The bug shouldn't be in the release, then resolve the sub-task with reason why it is not in the release.
> - The bug should be in, release manager either assigns to the developer to cherry-pick or cherry-picks himself.
This is a great workflow to suggest - as it requires that the
developer understand the value of pulling it back into the previous
feature release for a bug-fix release. The RM is then responsible for
"gating" fixes into that branch.
> The person doing the cherry-pick then does the following:
> - The commit message for the bug should include the subtask's bug id and not the original bug's id.
> - Once the cherry-pick is done, commit id should be placed with the sub task and the sub-task is resolved.
>
> There's a lot of benefits to this. The primary is that there's a trail on where the fixes went. It's also an official channel of communication between demand on where the bug is fixed, release manager, and developer.
>
> I like to ask that release managers do not accept a bug as resolved until the commit id has been put into the bug. I like to have this done automatically by git but I understand there's pushback on adding git-hooks to apache infra. Although, apache should really adopt this practice for all projects. It's a life-save when trying to figure out how a bug is fixed.
>
It's a bit of a challenge, in that you (as the RM) have to track all
bugs in the system really. However, if we are limiting the scope of
review to those tagged by developers for a specific release, then it
should work.
-chip
> --Alex
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Wednesday, November 07, 2012 2:25 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Rant: Request for better commit messages
>
> We'd better fire bugs on issues.apache.org/cloudstack, add a tag for each maintenance release(e.g. the upcoming 4.0.1), then release manager assign the bugs to each developer. It's the developer's responsibility to fix the bug on each maintenance branch, and write proper commit message, like, "BUGFIX: bug number ", then close the bug with the corresponding commit. It's easier for release manager to track the release procedure, and for QA team verify the bugs.
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Wednesday, November 07, 2012 11:11 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Rant: Request for better commit messages
>>
>> That's great, I'm fine with that if I need to create a bug for
>> everything that I know needs to be fixed in the 4.0 branch for
>> example. The header/tag in the commit message may not be something we
>> end up officially relying on by any means, but would help me as
>> someone who perhaps maintains a specific feature to take a quick look
>> at the logs in master and branch X and make sure that everything I
>> thought should be committed ended up in the branch, or at least
>> provides me a way to audit. I suppose that's a personal thing so I'll
>> just go forward doing that, but it brought up the question as to who
>> else might be able to use it or what the official way to tell the maintainer of a branch that something needs to be considered for inclusion.
>>
>> It seems like several things were missed at different points when 4.0
>> was getting cleaned up, and I don't know if that was due to not
>> following procedure or a lack of procedure.
>>
>>
>> On Wed, Nov 7, 2012 at 11:31 AM, John Burwell <jb...@basho.com>
>> wrote:
>>
>> > Marcus,
>> >
>> > To my mind, it does not seem appropriate for developers to be making
>> > release decisions at commit time. Instead, it feels more
>> > appropriate to me that these decisions are captured in a ticket that
>> > is referenced from the commit message. This separation allows the
>> > PMO/release management team/community to determine release contents
>> > based on
>> the
>> > results of review (via Review Board) and testing. If you feel your
>> > change is a high priority and should be in the next release, you
>> > would
>> capture that in the ticket.
>> > The PMO/release management team/community can then review that
>> > decision and comment/adjust as necessary. A commit message does not
>> > permit this type of collaboration. This separation also seems make
>> > the creation of release notes more straightforward as well.
>> >
>> > Thanks,
>> > -John
>> >
>> > On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com>
>> wrote:
>> >
>> > > Really I just want to make sure that a commit I make that I know
>> > > needs to be pushed into the next 4.0 bugfix release gets there.
>> > > Since someone else is in charge of maintaining 4.0 and merging bug
>> > > fixes, I can't do it myself, and I'm not really sure how it works
>> > > now. For example, does that maintainer look through a JIRA report
>> > > and only merge bugfixes listed
>> > there?
>> > >
>> > >
>> > > On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav
>> > > <ro...@citrix.com>
>> > wrote:
>> > >
>> > >> I'm not sure how (cherry picking, pull based on commit message)
>> > >> this
>> > will
>> > >> work, but it's good idea to mark the commit with some tag with
>> > >> say
>> > branch
>> > >> so we always commit on master?
>> > >> (Bugfix-for or Branch: <branches> )
>> > >> Branch: 4.0, master #(comma separated branch names).
>> > >> Bug-id: CLOUDSTACK-xxx
>> > >>
>> > >> This may be ambiguous, says some developer did not know if some
>> > >> commit would apply for some branch? Another issue is to encourage
>> > >> everyone of
>> > us
>> > >> to use this convention.
>> > >> If we could solve it, that would be great.
>> > >>
>> > >> ________________________________________
>> > >> From: Marcus Sorensen [shadowsor@gmail.com]
>> > >> Sent: Wednesday, November 07, 2012 8:56 PM
>> > >> To: cloudstack-dev@incubator.apache.org
>> > >> Subject: Re: Rant: Request for better commit messages
>> > >>
>> > >> Should we add a line to this commit message, where people can
>> > >> mark
>> > whether
>> > >> this patch should be considered for the next bugfix release? Or
>> > >> is that
>> > all
>> > >> handled/tracked through JIRA or some other means? I just thought
>> > >> it
>> > would
>> > >> be nice for the guy maintaining a release to be able to
>> > >> eventually pull
>> > in
>> > >> stuff based on the commit messages. It also allows the committers
>> > >> to
>> > give
>> > >> some sort of indication that commit X is important and needs to
>> > >> go into
>> > the
>> > >> bugfix.
>> > >>
>> > >> For now I'm just adding "Bugfix-for: 4.0" to my commits.
>> > >>
>> > >>
>> > >> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen
>> > >> <shadowsor@gmail.com
>> > >>> wrote:
>> > >>
>> > >>> Ok, this is now in master, see
>> > >>> 9ba7509c70fe82a8ce0b08826d424de452aef1d2
>> > >>>
>> > >>> set it up by running the following from your incubator-cloudstack dir:
>> > >>>
>> > >>> 'ln -s ../../tools/git/prepare-commit-msg
>> > .git/hooks/prepare-commit-msg'
>> > >>>
>> > >>> Developers can also optionally commit different
>> > >>> prepare-commit-msg scripts for each branch, and the link will point to the one you're on.
>> > >>>
>> > >>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav
>> > >>> <ro...@citrix.com>
>> > >>> wrote:
>> > >>>>
>> > >>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen
>> <sh...@gmail.com>
>> > >> wrote:
>> > >>>>
>> > >>>>> I'm by no means a git guru, but in searching around it didn't
>> > >>>>> seem
>> > >> like
>> > >>>>> there was a way to enforce the application of hooks from the
>> > >>>>> repo
>> > >> side.
>> > >>>>> I'm not sure we'd want to anyway. I was just going to commit
>> > >>>>> the file
>> > >>> and
>> > >>>>> then add instructions on the wiki for people to add it in
>> > >>>>> their local
>> > >>> repo
>> > >>>>> config.
>> > >>>>
>> > >>>> I think that's fine. Instead of hooks what people can do is add
>> > >>>> a
>> > >> commit
>> > >>> template to their local git configuration.
>> > >>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
>> > >>>>
>> > >>>> Checkout commit.template, add following to your ~/.gitconfig:
>> > >>>> [commit]
>> > >>>> template = ~/.gitmessage
>> > >>>>
>> > >>>> And create a ~/.gitmessage like:
>> > >>>> #Header: one line explaination
>> > >>>> #
>> > >>>> #Body of commit message explaining things in more detail,
>> > >>>> possibly
>> > >>> giving some
>> > >>>> #background about the issue being fixed, etc. Maybe use bullets:
>> > >>>> # - Write in present tense
>> > >>>> # - Keep text width of commit message within 80 characters.
>> > >>>> #
>> > >>>> #Use more than one paragraphs, that's is fine.
>> > >>>> #
>> > >>>> #Reviewed-by: Person or link to review on review.apache.org
>> > >>>> #Reported-by: whoever-reported-it, if applicable
>> > >>>> #Signed-off-by: Your Name <yo...@yourhost.com>
>> > >>>>
>> > >>>> Now every time one does git commit, she will see this in their
>> > >>>> editor
>> > >>> and use this as a reminder to write better commit message.
>> > >>>> For example my:
>> > >>>> gitconfig:
>> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
>> > >>>> gitmessage:
>> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
>> > >>>>
>> > >>>> Regards.
>> > >>>>
>> > >>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav"
>> > >>>>> <ro...@citrix.com>
>> > >> wrote:
>> > >>>>>
>> > >>>>>>
>> > >>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen
>> > >>>>>> <sh...@gmail.com>
>> > >>> wrote:
>> > >>>>>>
>> > >>>>>>> Sure thing. A few questions:
>> > >>>>>>>
>> > >>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be
>> > >>>>>>> changed to simply "Bug id:"?
>> > >>>>>>
>> > >>>>>> I guess as there are already several commits that follow
>> > >>> CLOUDSTACK-BUGID
>> > >>>>>> convention, we should continue that.
>> > >>>>>> Also, there are commits with bug id's of old jira, like
>> > >>>>>> CS-16414
>> > etc.
>> > >>>>>>
>> > >>>>>>> I'm assuming that if the commit is a bug fix, the fix will
>> > >>>>>>> already be described in the summary and detail of the
>> > >> commit.
>> > >>>>>>> Or are we looking for something else here other than a
>> description?
>> > >> I
>> > >>>>>>> could just see this being redundant, but perhaps I don't
>> > >>>>>>> understand what's being asked for on that line. Should id
>> > >>>>>>> describe the bug
>> > >> itself
>> > >>>>>>> in one line, rather than the bug fix?
>> > >>>>>>
>> > >>>>>> Whatever makes sense, I usually write what that commit does
>> > >>>>>> in one
>> > >>> line.
>> > >>>>>>
>> > >>>>>>>
>> > >>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
>> > >> message.
>> > >>>>>>> I realize that some people will have their own configs that
>> > >>>>>>> already
>> > >> do
>> > >>>>>>> this, or be used to using -s to auto-add it to the message,
>> > >>>>>>> but judging by the logs it seems that the majority don't. So
>> > >>>>>>> hopefully this doesn't upset anyone horribly :-) They can
>> > >>>>>>> always change their copy since the hook will need to be
>> > >>>>>>> manually
>> installed.
>> > >>>>>>
>> > >>>>>> I've just put up bunch of guidelines on the wiki, let's take
>> > whatever
>> > >>>>>> seems good and follow whatever makes sense.
>> > >>>>>> My whole intension was to bring up the issue that a short
>> > >>>>>> commit
>> > >>> message
>> > >>>>>> makes it hard for folks to follow commits.
>> > >>>>>>
>> > >>>>>>> Attached is an example commit message generated by the hook
>> so far.
>> > >>>>>>
>> > >>>>>> Cool, I guess you would have to contact someone from ASF
>> > >>>>>> infra to
>> > set
>> > >>> this
>> > >>>>>> up.
>> > >>>>>>
>> > >>>>>>> I
>> > >>>>>>> left in the default comment message as well, simply because
>> > >>>>>>> it includes a list of what's modified,etc for reference when
>> > >>>>>>> typing up the notes.
>> > >>>>>>
>> > >>>>>> --
>> > >>>>>> Rohit
>> > >>>>>>
>> > >>>>>>>
>> > >>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
>> > >> rohit.yadav@citrix.com>
>> > >>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
>> > >>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
>> CommitM
>> > essages
>> > >>>>>>>>
>> > >>>>>>>> Pl. check and edit as needed.
>> > >>>>>>>>
>> > >>>>>>>> One more thing, I checked looks like ASF infra guys have
>> > >>>>>>>> upgraded
>> > >>> their
>> > >>>>>> review board.
>> > >>>>>>>> The bug (
>> > >>>>>>
>> > >>>
>> > >>
>> >
>> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690
>> > &ts=1343826104
>> > >>> )
>> > >>>>>> got fixed so now downloading the diff downloads the actual
>> > >>>>>> uploaded
>> > >> git
>> > >>>>>> formatted patch.
>> > >>>>>>>>
>> > >>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen
>> > >>>>>>>> <sh...@gmail.com>
>> > >>>>>> wrote:
>> > >>>>>>>>
>> > >>>>>>>>> Might be cool if we could make/document git hooks for a
>> > >>>>>>>>> standard
>> > >>>>>> message form.
>> > >>>>>>>>
>> > >>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks
>> > >>>>>>>> to ASF
>> > >>> repo
>> > >>>>>> that would be great.
>> > >>>>>>>>
>> > >>>>>>>> Regards.
>> > >>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
>> > >> wido@widodh.nl
>> > >>>>
>> > >>>>>> wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> Perhaps we could document this on the wiki, as part of a
>> > nascent
>> > >>>>>> coding
>> > >>>>>>>>>>> standards policy?
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> I'd say so. We already have a coding convention, it's
>> > >>>>>>>>>> just a
>> > >> small
>> > >>>>>> step to
>> > >>>>>>>>>> add a commit convention.
>> > >>>>>>>>>>
>> > >>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
>> > >>>>>>>>>>
>> > >>>>>>>>>> Wido
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
>> > >>> rohit.yadav@citrix.com
>> > >>>>>>>
>> > >>>>>>>>>>> wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>> Hi folks,
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> With due respect, I would like to request all the
>> > >>>>>>>>>>>> committers
>> > >> and
>> > >>>>>>>>>>>> contributors to write better commit message. [0]
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> For example, a good commit message:
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c
>> > ommit;h=384c03e42578f17432a483d5828aad64175d9c49
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> A good commit message subject should have something
>> like
>> > >>>>>>>>>>>> this
>> > >>> with
>> > >>>>>> 80
>> > >>>>>>>>>>>> chars width:
>> > >>>>>>>>>>>> <Header line>: <short log description> <blank line>
>> > >>>>>>>>>>>> <body of commit message, explain things why, what, how, etc.
>> > >>> giving
>> > >>>>>>>>>>>> background>
>> > >>>>>>>>>>>> <bulleted points help>
>> > >>>>>>>>>>>> <blank line>
>> > >>>>>>>>>>>> <Reported-by: if it's a bug>
>> > >>>>>>>>>>>> <Reviewed-by: if it was reviewed>
>> > >>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> This is what we follow on
>> > >>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they
>> > >>>>>>>>>>>> are
>> > >> crazy
>> > >>>>>> about
>> > >>>>>>>>>>>> commits and patches, they just don't accept junk
>> > >>>>>>>>>>>> messages, even if code is fine. You may check, there is
>> > >>>>>>>>>>>> no or
>> > >> few
>> > >>>>>>>>>>>> reverts.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> When something breaks, I check all last commits and do
>> > >>>>>>>>>>>> a git
>> > >> log
>> > >>> -p
>> > >>>>>>>>>>>> <file>
>> > >>>>>>>>>>>> to go through recent changes to a file, in case I think
>> > >> something
>> > >>>>>> broke I
>> > >>>>>>>>>>>> like to identify the changes that may have caused it
>> > >>>>>>>>>>>> instead
>> > of
>> > >>>>>> fixing it
>> > >>>>>>>>>>>> which may introduce further problems. I use tig and zsh
>> > >>>>>>>>>>>> to
>> > >>> regularly
>> > >>>>>>>>>>>> follow
>> > >>>>>>>>>>>> commits and read commit messages.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> [0]
>> > >> https://github.com/torvalds/subsurface/blob/master/README(at
>> > >>>>>> the
>> > >>>>>>>>>>>> end)
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> Regards.
>> > >>>>>>>>>>>> PS. I had to email about it as we're uncool with our
>> > >>>>>>>>>>>> git
>> > commit
>> > >>>>>> habits,
>> > >>>>>>>>>>>> we
>> > >>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix
>> > >>>>>>>>>>>> our
>> > >> habits.
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c ommit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c
>> > ommit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c ommit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c
>> > ommit;h=828fa3389bbe7cd0378c4e55152d671932badca2
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c
>> > ommit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c ommit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c
>> > ommit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>
>> > >>>
>> > >>
>> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
>> > =c ommit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>> <examplecommitmsg.txt>
>> > >>>>>>
>> > >>>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> >
>
RE: Rant: Request for better commit messages
Posted by Alex Huang <Al...@citrix.com>.
We should remember that we didn't have Jira setup until very late into the 4.0 release. There were a lot of things that leaked through because of that.
We should make use of the Jira functionalities.
These steps can be performed by everyone.
- A bug is filed in issues.apache.org/cloudstack. This should target the releases that it is to be fixed in.
- If the bug needs to be propagated to another release, a subtask is created for that release.
The release manager decides on whether the bug should be put into the release. Upon which he can do the following things.
- The bug shouldn't be in the release, then resolve the sub-task with reason why it is not in the release.
- The bug should be in, release manager either assigns to the developer to cherry-pick or cherry-picks himself.
The person doing the cherry-pick then does the following:
- The commit message for the bug should include the subtask's bug id and not the original bug's id.
- Once the cherry-pick is done, commit id should be placed with the sub task and the sub-task is resolved.
There's a lot of benefits to this. The primary is that there's a trail on where the fixes went. It's also an official channel of communication between demand on where the bug is fixed, release manager, and developer.
I like to ask that release managers do not accept a bug as resolved until the commit id has been put into the bug. I like to have this done automatically by git but I understand there's pushback on adding git-hooks to apache infra. Although, apache should really adopt this practice for all projects. It's a life-save when trying to figure out how a bug is fixed.
--Alex
-----Original Message-----
From: Edison Su [mailto:Edison.su@citrix.com]
Sent: Wednesday, November 07, 2012 2:25 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Rant: Request for better commit messages
We'd better fire bugs on issues.apache.org/cloudstack, add a tag for each maintenance release(e.g. the upcoming 4.0.1), then release manager assign the bugs to each developer. It's the developer's responsibility to fix the bug on each maintenance branch, and write proper commit message, like, "BUGFIX: bug number ", then close the bug with the corresponding commit. It's easier for release manager to track the release procedure, and for QA team verify the bugs.
> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Wednesday, November 07, 2012 11:11 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Rant: Request for better commit messages
>
> That's great, I'm fine with that if I need to create a bug for
> everything that I know needs to be fixed in the 4.0 branch for
> example. The header/tag in the commit message may not be something we
> end up officially relying on by any means, but would help me as
> someone who perhaps maintains a specific feature to take a quick look
> at the logs in master and branch X and make sure that everything I
> thought should be committed ended up in the branch, or at least
> provides me a way to audit. I suppose that's a personal thing so I'll
> just go forward doing that, but it brought up the question as to who
> else might be able to use it or what the official way to tell the maintainer of a branch that something needs to be considered for inclusion.
>
> It seems like several things were missed at different points when 4.0
> was getting cleaned up, and I don't know if that was due to not
> following procedure or a lack of procedure.
>
>
> On Wed, Nov 7, 2012 at 11:31 AM, John Burwell <jb...@basho.com>
> wrote:
>
> > Marcus,
> >
> > To my mind, it does not seem appropriate for developers to be making
> > release decisions at commit time. Instead, it feels more
> > appropriate to me that these decisions are captured in a ticket that
> > is referenced from the commit message. This separation allows the
> > PMO/release management team/community to determine release contents
> > based on
> the
> > results of review (via Review Board) and testing. If you feel your
> > change is a high priority and should be in the next release, you
> > would
> capture that in the ticket.
> > The PMO/release management team/community can then review that
> > decision and comment/adjust as necessary. A commit message does not
> > permit this type of collaboration. This separation also seems make
> > the creation of release notes more straightforward as well.
> >
> > Thanks,
> > -John
> >
> > On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> >
> > > Really I just want to make sure that a commit I make that I know
> > > needs to be pushed into the next 4.0 bugfix release gets there.
> > > Since someone else is in charge of maintaining 4.0 and merging bug
> > > fixes, I can't do it myself, and I'm not really sure how it works
> > > now. For example, does that maintainer look through a JIRA report
> > > and only merge bugfixes listed
> > there?
> > >
> > >
> > > On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav
> > > <ro...@citrix.com>
> > wrote:
> > >
> > >> I'm not sure how (cherry picking, pull based on commit message)
> > >> this
> > will
> > >> work, but it's good idea to mark the commit with some tag with
> > >> say
> > branch
> > >> so we always commit on master?
> > >> (Bugfix-for or Branch: <branches> )
> > >> Branch: 4.0, master #(comma separated branch names).
> > >> Bug-id: CLOUDSTACK-xxx
> > >>
> > >> This may be ambiguous, says some developer did not know if some
> > >> commit would apply for some branch? Another issue is to encourage
> > >> everyone of
> > us
> > >> to use this convention.
> > >> If we could solve it, that would be great.
> > >>
> > >> ________________________________________
> > >> From: Marcus Sorensen [shadowsor@gmail.com]
> > >> Sent: Wednesday, November 07, 2012 8:56 PM
> > >> To: cloudstack-dev@incubator.apache.org
> > >> Subject: Re: Rant: Request for better commit messages
> > >>
> > >> Should we add a line to this commit message, where people can
> > >> mark
> > whether
> > >> this patch should be considered for the next bugfix release? Or
> > >> is that
> > all
> > >> handled/tracked through JIRA or some other means? I just thought
> > >> it
> > would
> > >> be nice for the guy maintaining a release to be able to
> > >> eventually pull
> > in
> > >> stuff based on the commit messages. It also allows the committers
> > >> to
> > give
> > >> some sort of indication that commit X is important and needs to
> > >> go into
> > the
> > >> bugfix.
> > >>
> > >> For now I'm just adding "Bugfix-for: 4.0" to my commits.
> > >>
> > >>
> > >> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen
> > >> <shadowsor@gmail.com
> > >>> wrote:
> > >>
> > >>> Ok, this is now in master, see
> > >>> 9ba7509c70fe82a8ce0b08826d424de452aef1d2
> > >>>
> > >>> set it up by running the following from your incubator-cloudstack dir:
> > >>>
> > >>> 'ln -s ../../tools/git/prepare-commit-msg
> > .git/hooks/prepare-commit-msg'
> > >>>
> > >>> Developers can also optionally commit different
> > >>> prepare-commit-msg scripts for each branch, and the link will point to the one you're on.
> > >>>
> > >>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav
> > >>> <ro...@citrix.com>
> > >>> wrote:
> > >>>>
> > >>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen
> <sh...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>>> I'm by no means a git guru, but in searching around it didn't
> > >>>>> seem
> > >> like
> > >>>>> there was a way to enforce the application of hooks from the
> > >>>>> repo
> > >> side.
> > >>>>> I'm not sure we'd want to anyway. I was just going to commit
> > >>>>> the file
> > >>> and
> > >>>>> then add instructions on the wiki for people to add it in
> > >>>>> their local
> > >>> repo
> > >>>>> config.
> > >>>>
> > >>>> I think that's fine. Instead of hooks what people can do is add
> > >>>> a
> > >> commit
> > >>> template to their local git configuration.
> > >>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> > >>>>
> > >>>> Checkout commit.template, add following to your ~/.gitconfig:
> > >>>> [commit]
> > >>>> template = ~/.gitmessage
> > >>>>
> > >>>> And create a ~/.gitmessage like:
> > >>>> #Header: one line explaination
> > >>>> #
> > >>>> #Body of commit message explaining things in more detail,
> > >>>> possibly
> > >>> giving some
> > >>>> #background about the issue being fixed, etc. Maybe use bullets:
> > >>>> # - Write in present tense
> > >>>> # - Keep text width of commit message within 80 characters.
> > >>>> #
> > >>>> #Use more than one paragraphs, that's is fine.
> > >>>> #
> > >>>> #Reviewed-by: Person or link to review on review.apache.org
> > >>>> #Reported-by: whoever-reported-it, if applicable
> > >>>> #Signed-off-by: Your Name <yo...@yourhost.com>
> > >>>>
> > >>>> Now every time one does git commit, she will see this in their
> > >>>> editor
> > >>> and use this as a reminder to write better commit message.
> > >>>> For example my:
> > >>>> gitconfig:
> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > >>>> gitmessage:
> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> > >>>>
> > >>>> Regards.
> > >>>>
> > >>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav"
> > >>>>> <ro...@citrix.com>
> > >> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen
> > >>>>>> <sh...@gmail.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Sure thing. A few questions:
> > >>>>>>>
> > >>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be
> > >>>>>>> changed to simply "Bug id:"?
> > >>>>>>
> > >>>>>> I guess as there are already several commits that follow
> > >>> CLOUDSTACK-BUGID
> > >>>>>> convention, we should continue that.
> > >>>>>> Also, there are commits with bug id's of old jira, like
> > >>>>>> CS-16414
> > etc.
> > >>>>>>
> > >>>>>>> I'm assuming that if the commit is a bug fix, the fix will
> > >>>>>>> already be described in the summary and detail of the
> > >> commit.
> > >>>>>>> Or are we looking for something else here other than a
> description?
> > >> I
> > >>>>>>> could just see this being redundant, but perhaps I don't
> > >>>>>>> understand what's being asked for on that line. Should id
> > >>>>>>> describe the bug
> > >> itself
> > >>>>>>> in one line, rather than the bug fix?
> > >>>>>>
> > >>>>>> Whatever makes sense, I usually write what that commit does
> > >>>>>> in one
> > >>> line.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
> > >> message.
> > >>>>>>> I realize that some people will have their own configs that
> > >>>>>>> already
> > >> do
> > >>>>>>> this, or be used to using -s to auto-add it to the message,
> > >>>>>>> but judging by the logs it seems that the majority don't. So
> > >>>>>>> hopefully this doesn't upset anyone horribly :-) They can
> > >>>>>>> always change their copy since the hook will need to be
> > >>>>>>> manually
> installed.
> > >>>>>>
> > >>>>>> I've just put up bunch of guidelines on the wiki, let's take
> > whatever
> > >>>>>> seems good and follow whatever makes sense.
> > >>>>>> My whole intension was to bring up the issue that a short
> > >>>>>> commit
> > >>> message
> > >>>>>> makes it hard for folks to follow commits.
> > >>>>>>
> > >>>>>>> Attached is an example commit message generated by the hook
> so far.
> > >>>>>>
> > >>>>>> Cool, I guess you would have to contact someone from ASF
> > >>>>>> infra to
> > set
> > >>> this
> > >>>>>> up.
> > >>>>>>
> > >>>>>>> I
> > >>>>>>> left in the default comment message as well, simply because
> > >>>>>>> it includes a list of what's modified,etc for reference when
> > >>>>>>> typing up the notes.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Rohit
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
> > >> rohit.yadav@citrix.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> > >>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
> CommitM
> > essages
> > >>>>>>>>
> > >>>>>>>> Pl. check and edit as needed.
> > >>>>>>>>
> > >>>>>>>> One more thing, I checked looks like ASF infra guys have
> > >>>>>>>> upgraded
> > >>> their
> > >>>>>> review board.
> > >>>>>>>> The bug (
> > >>>>>>
> > >>>
> > >>
> >
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690
> > &ts=1343826104
> > >>> )
> > >>>>>> got fixed so now downloading the diff downloads the actual
> > >>>>>> uploaded
> > >> git
> > >>>>>> formatted patch.
> > >>>>>>>>
> > >>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen
> > >>>>>>>> <sh...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Might be cool if we could make/document git hooks for a
> > >>>>>>>>> standard
> > >>>>>> message form.
> > >>>>>>>>
> > >>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks
> > >>>>>>>> to ASF
> > >>> repo
> > >>>>>> that would be great.
> > >>>>>>>>
> > >>>>>>>> Regards.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
> > >> wido@widodh.nl
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Perhaps we could document this on the wiki, as part of a
> > nascent
> > >>>>>> coding
> > >>>>>>>>>>> standards policy?
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> I'd say so. We already have a coding convention, it's
> > >>>>>>>>>> just a
> > >> small
> > >>>>>> step to
> > >>>>>>>>>> add a commit convention.
> > >>>>>>>>>>
> > >>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> > >>>>>>>>>>
> > >>>>>>>>>> Wido
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> > >>> rohit.yadav@citrix.com
> > >>>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi folks,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> With due respect, I would like to request all the
> > >>>>>>>>>>>> committers
> > >> and
> > >>>>>>>>>>>> contributors to write better commit message. [0]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> For example, a good commit message:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c
> > ommit;h=384c03e42578f17432a483d5828aad64175d9c49
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> A good commit message subject should have something
> like
> > >>>>>>>>>>>> this
> > >>> with
> > >>>>>> 80
> > >>>>>>>>>>>> chars width:
> > >>>>>>>>>>>> <Header line>: <short log description> <blank line>
> > >>>>>>>>>>>> <body of commit message, explain things why, what, how, etc.
> > >>> giving
> > >>>>>>>>>>>> background>
> > >>>>>>>>>>>> <bulleted points help>
> > >>>>>>>>>>>> <blank line>
> > >>>>>>>>>>>> <Reported-by: if it's a bug>
> > >>>>>>>>>>>> <Reviewed-by: if it was reviewed>
> > >>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> This is what we follow on
> > >>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they
> > >>>>>>>>>>>> are
> > >> crazy
> > >>>>>> about
> > >>>>>>>>>>>> commits and patches, they just don't accept junk
> > >>>>>>>>>>>> messages, even if code is fine. You may check, there is
> > >>>>>>>>>>>> no or
> > >> few
> > >>>>>>>>>>>> reverts.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> When something breaks, I check all last commits and do
> > >>>>>>>>>>>> a git
> > >> log
> > >>> -p
> > >>>>>>>>>>>> <file>
> > >>>>>>>>>>>> to go through recent changes to a file, in case I think
> > >> something
> > >>>>>> broke I
> > >>>>>>>>>>>> like to identify the changes that may have caused it
> > >>>>>>>>>>>> instead
> > of
> > >>>>>> fixing it
> > >>>>>>>>>>>> which may introduce further problems. I use tig and zsh
> > >>>>>>>>>>>> to
> > >>> regularly
> > >>>>>>>>>>>> follow
> > >>>>>>>>>>>> commits and read commit messages.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [0]
> > >> https://github.com/torvalds/subsurface/blob/master/README(at
> > >>>>>> the
> > >>>>>>>>>>>> end)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Regards.
> > >>>>>>>>>>>> PS. I had to email about it as we're uncool with our
> > >>>>>>>>>>>> git
> > commit
> > >>>>>> habits,
> > >>>>>>>>>>>> we
> > >>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix
> > >>>>>>>>>>>> our
> > >> habits.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c ommit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c
> > ommit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c ommit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c
> > ommit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c
> > ommit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c ommit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c
> > ommit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a
> > =c ommit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>> <examplecommitmsg.txt>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
RE: Rant: Request for better commit messages
Posted by Edison Su <Ed...@citrix.com>.
We'd better fire bugs on issues.apache.org/cloudstack, add a tag for each maintenance release(e.g. the upcoming 4.0.1), then release manager assign the bugs to each developer. It's the developer's responsibility to fix the bug on each maintenance branch, and write proper commit message, like, "BUGFIX: bug number ", then close the bug with the corresponding commit. It's easier for release manager to track the release procedure, and for QA team verify the bugs.
> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Wednesday, November 07, 2012 11:11 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Rant: Request for better commit messages
>
> That's great, I'm fine with that if I need to create a bug for everything that I
> know needs to be fixed in the 4.0 branch for example. The header/tag in the
> commit message may not be something we end up officially relying on by any
> means, but would help me as someone who perhaps maintains a specific
> feature to take a quick look at the logs in master and branch X and make sure
> that everything I thought should be committed ended up in the branch, or at
> least provides me a way to audit. I suppose that's a personal thing so I'll just
> go forward doing that, but it brought up the question as to who else might be
> able to use it or what the official way to tell the maintainer of a branch that
> something needs to be considered for inclusion.
>
> It seems like several things were missed at different points when 4.0 was
> getting cleaned up, and I don't know if that was due to not following
> procedure or a lack of procedure.
>
>
> On Wed, Nov 7, 2012 at 11:31 AM, John Burwell <jb...@basho.com>
> wrote:
>
> > Marcus,
> >
> > To my mind, it does not seem appropriate for developers to be making
> > release decisions at commit time. Instead, it feels more appropriate
> > to me that these decisions are captured in a ticket that is referenced
> > from the commit message. This separation allows the PMO/release
> > management team/community to determine release contents based on
> the
> > results of review (via Review Board) and testing. If you feel your
> > change is a high priority and should be in the next release, you would
> capture that in the ticket.
> > The PMO/release management team/community can then review that
> > decision and comment/adjust as necessary. A commit message does not
> > permit this type of collaboration. This separation also seems make
> > the creation of release notes more straightforward as well.
> >
> > Thanks,
> > -John
> >
> > On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> >
> > > Really I just want to make sure that a commit I make that I know
> > > needs to be pushed into the next 4.0 bugfix release gets there.
> > > Since someone else is in charge of maintaining 4.0 and merging bug
> > > fixes, I can't do it myself, and I'm not really sure how it works
> > > now. For example, does that maintainer look through a JIRA report
> > > and only merge bugfixes listed
> > there?
> > >
> > >
> > > On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav
> > > <ro...@citrix.com>
> > wrote:
> > >
> > >> I'm not sure how (cherry picking, pull based on commit message)
> > >> this
> > will
> > >> work, but it's good idea to mark the commit with some tag with say
> > branch
> > >> so we always commit on master?
> > >> (Bugfix-for or Branch: <branches> )
> > >> Branch: 4.0, master #(comma separated branch names).
> > >> Bug-id: CLOUDSTACK-xxx
> > >>
> > >> This may be ambiguous, says some developer did not know if some
> > >> commit would apply for some branch? Another issue is to encourage
> > >> everyone of
> > us
> > >> to use this convention.
> > >> If we could solve it, that would be great.
> > >>
> > >> ________________________________________
> > >> From: Marcus Sorensen [shadowsor@gmail.com]
> > >> Sent: Wednesday, November 07, 2012 8:56 PM
> > >> To: cloudstack-dev@incubator.apache.org
> > >> Subject: Re: Rant: Request for better commit messages
> > >>
> > >> Should we add a line to this commit message, where people can mark
> > whether
> > >> this patch should be considered for the next bugfix release? Or is
> > >> that
> > all
> > >> handled/tracked through JIRA or some other means? I just thought it
> > would
> > >> be nice for the guy maintaining a release to be able to eventually
> > >> pull
> > in
> > >> stuff based on the commit messages. It also allows the committers
> > >> to
> > give
> > >> some sort of indication that commit X is important and needs to go
> > >> into
> > the
> > >> bugfix.
> > >>
> > >> For now I'm just adding "Bugfix-for: 4.0" to my commits.
> > >>
> > >>
> > >> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen
> > >> <shadowsor@gmail.com
> > >>> wrote:
> > >>
> > >>> Ok, this is now in master, see
> > >>> 9ba7509c70fe82a8ce0b08826d424de452aef1d2
> > >>>
> > >>> set it up by running the following from your incubator-cloudstack dir:
> > >>>
> > >>> 'ln -s ../../tools/git/prepare-commit-msg
> > .git/hooks/prepare-commit-msg'
> > >>>
> > >>> Developers can also optionally commit different prepare-commit-msg
> > >>> scripts for each branch, and the link will point to the one you're on.
> > >>>
> > >>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav
> > >>> <ro...@citrix.com>
> > >>> wrote:
> > >>>>
> > >>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen
> <sh...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>>> I'm by no means a git guru, but in searching around it didn't
> > >>>>> seem
> > >> like
> > >>>>> there was a way to enforce the application of hooks from the
> > >>>>> repo
> > >> side.
> > >>>>> I'm not sure we'd want to anyway. I was just going to commit the
> > >>>>> file
> > >>> and
> > >>>>> then add instructions on the wiki for people to add it in their
> > >>>>> local
> > >>> repo
> > >>>>> config.
> > >>>>
> > >>>> I think that's fine. Instead of hooks what people can do is add a
> > >> commit
> > >>> template to their local git configuration.
> > >>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> > >>>>
> > >>>> Checkout commit.template, add following to your ~/.gitconfig:
> > >>>> [commit]
> > >>>> template = ~/.gitmessage
> > >>>>
> > >>>> And create a ~/.gitmessage like:
> > >>>> #Header: one line explaination
> > >>>> #
> > >>>> #Body of commit message explaining things in more detail,
> > >>>> possibly
> > >>> giving some
> > >>>> #background about the issue being fixed, etc. Maybe use bullets:
> > >>>> # - Write in present tense
> > >>>> # - Keep text width of commit message within 80 characters.
> > >>>> #
> > >>>> #Use more than one paragraphs, that's is fine.
> > >>>> #
> > >>>> #Reviewed-by: Person or link to review on review.apache.org
> > >>>> #Reported-by: whoever-reported-it, if applicable
> > >>>> #Signed-off-by: Your Name <yo...@yourhost.com>
> > >>>>
> > >>>> Now every time one does git commit, she will see this in their
> > >>>> editor
> > >>> and use this as a reminder to write better commit message.
> > >>>> For example my:
> > >>>> gitconfig:
> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > >>>> gitmessage:
> > >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> > >>>>
> > >>>> Regards.
> > >>>>
> > >>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
> > >> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen
> > >>>>>> <sh...@gmail.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Sure thing. A few questions:
> > >>>>>>>
> > >>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed
> > >>>>>>> to simply "Bug id:"?
> > >>>>>>
> > >>>>>> I guess as there are already several commits that follow
> > >>> CLOUDSTACK-BUGID
> > >>>>>> convention, we should continue that.
> > >>>>>> Also, there are commits with bug id's of old jira, like
> > >>>>>> CS-16414
> > etc.
> > >>>>>>
> > >>>>>>> I'm assuming that if the commit is a bug fix, the fix will
> > >>>>>>> already be described in the summary and detail of the
> > >> commit.
> > >>>>>>> Or are we looking for something else here other than a
> description?
> > >> I
> > >>>>>>> could just see this being redundant, but perhaps I don't
> > >>>>>>> understand what's being asked for on that line. Should id
> > >>>>>>> describe the bug
> > >> itself
> > >>>>>>> in one line, rather than the bug fix?
> > >>>>>>
> > >>>>>> Whatever makes sense, I usually write what that commit does in
> > >>>>>> one
> > >>> line.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
> > >> message.
> > >>>>>>> I realize that some people will have their own configs that
> > >>>>>>> already
> > >> do
> > >>>>>>> this, or be used to using -s to auto-add it to the message,
> > >>>>>>> but judging by the logs it seems that the majority don't. So
> > >>>>>>> hopefully this doesn't upset anyone horribly :-) They can
> > >>>>>>> always change their copy since the hook will need to be manually
> installed.
> > >>>>>>
> > >>>>>> I've just put up bunch of guidelines on the wiki, let's take
> > whatever
> > >>>>>> seems good and follow whatever makes sense.
> > >>>>>> My whole intension was to bring up the issue that a short
> > >>>>>> commit
> > >>> message
> > >>>>>> makes it hard for folks to follow commits.
> > >>>>>>
> > >>>>>>> Attached is an example commit message generated by the hook
> so far.
> > >>>>>>
> > >>>>>> Cool, I guess you would have to contact someone from ASF infra
> > >>>>>> to
> > set
> > >>> this
> > >>>>>> up.
> > >>>>>>
> > >>>>>>> I
> > >>>>>>> left in the default comment message as well, simply because it
> > >>>>>>> includes a list of what's modified,etc for reference when
> > >>>>>>> typing up the notes.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Rohit
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
> > >> rohit.yadav@citrix.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> > >>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-
> CommitM
> > essages
> > >>>>>>>>
> > >>>>>>>> Pl. check and edit as needed.
> > >>>>>>>>
> > >>>>>>>> One more thing, I checked looks like ASF infra guys have
> > >>>>>>>> upgraded
> > >>> their
> > >>>>>> review board.
> > >>>>>>>> The bug (
> > >>>>>>
> > >>>
> > >>
> >
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690
> > &ts=1343826104
> > >>> )
> > >>>>>> got fixed so now downloading the diff downloads the actual
> > >>>>>> uploaded
> > >> git
> > >>>>>> formatted patch.
> > >>>>>>>>
> > >>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen
> > >>>>>>>> <sh...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Might be cool if we could make/document git hooks for a
> > >>>>>>>>> standard
> > >>>>>> message form.
> > >>>>>>>>
> > >>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks to
> > >>>>>>>> ASF
> > >>> repo
> > >>>>>> that would be great.
> > >>>>>>>>
> > >>>>>>>> Regards.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
> > >> wido@widodh.nl
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Perhaps we could document this on the wiki, as part of a
> > nascent
> > >>>>>> coding
> > >>>>>>>>>>> standards policy?
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> I'd say so. We already have a coding convention, it's just
> > >>>>>>>>>> a
> > >> small
> > >>>>>> step to
> > >>>>>>>>>> add a commit convention.
> > >>>>>>>>>>
> > >>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> > >>>>>>>>>>
> > >>>>>>>>>> Wido
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> > >>> rohit.yadav@citrix.com
> > >>>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi folks,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> With due respect, I would like to request all the
> > >>>>>>>>>>>> committers
> > >> and
> > >>>>>>>>>>>> contributors to write better commit message. [0]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> For example, a good commit message:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=384c03e42578f17432a483d5828aad64175d9c49
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> A good commit message subject should have something
> like
> > >>>>>>>>>>>> this
> > >>> with
> > >>>>>> 80
> > >>>>>>>>>>>> chars width:
> > >>>>>>>>>>>> <Header line>: <short log description> <blank line> <body
> > >>>>>>>>>>>> of commit message, explain things why, what, how, etc.
> > >>> giving
> > >>>>>>>>>>>> background>
> > >>>>>>>>>>>> <bulleted points help>
> > >>>>>>>>>>>> <blank line>
> > >>>>>>>>>>>> <Reported-by: if it's a bug>
> > >>>>>>>>>>>> <Reviewed-by: if it was reviewed>
> > >>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> This is what we follow on
> > >>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they
> > >>>>>>>>>>>> are
> > >> crazy
> > >>>>>> about
> > >>>>>>>>>>>> commits and patches, they just don't accept junk
> > >>>>>>>>>>>> messages, even if code is fine. You may check, there is
> > >>>>>>>>>>>> no or
> > >> few
> > >>>>>>>>>>>> reverts.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> When something breaks, I check all last commits and do a
> > >>>>>>>>>>>> git
> > >> log
> > >>> -p
> > >>>>>>>>>>>> <file>
> > >>>>>>>>>>>> to go through recent changes to a file, in case I think
> > >> something
> > >>>>>> broke I
> > >>>>>>>>>>>> like to identify the changes that may have caused it
> > >>>>>>>>>>>> instead
> > of
> > >>>>>> fixing it
> > >>>>>>>>>>>> which may introduce further problems. I use tig and zsh
> > >>>>>>>>>>>> to
> > >>> regularly
> > >>>>>>>>>>>> follow
> > >>>>>>>>>>>> commits and read commit messages.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [0]
> > >> https://github.com/torvalds/subsurface/blob/master/README(at
> > >>>>>> the
> > >>>>>>>>>>>> end)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Regards.
> > >>>>>>>>>>>> PS. I had to email about it as we're uncool with our git
> > commit
> > >>>>>> habits,
> > >>>>>>>>>>>> we
> > >>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix our
> > >> habits.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>
> > >>>
> > >>
> > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=c
> > ommit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>> <examplecommitmsg.txt>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> >
> >
Re: Rant: Request for better commit messages
Posted by Marcus Sorensen <sh...@gmail.com>.
That's great, I'm fine with that if I need to create a bug for everything
that I know needs to be fixed in the 4.0 branch for example. The
header/tag in the commit message may not be something we end up officially
relying on by any means, but would help me as someone who perhaps maintains
a specific feature to take a quick look at the logs in master and branch X
and make sure that everything I thought should be committed ended up in the
branch, or at least provides me a way to audit. I suppose that's a personal
thing so I'll just go forward doing that, but it brought up the question as
to who else might be able to use it or what the official way to tell the
maintainer of a branch that something needs to be considered for inclusion.
It seems like several things were missed at different points when 4.0 was
getting cleaned up, and I don't know if that was due to not following
procedure or a lack of procedure.
On Wed, Nov 7, 2012 at 11:31 AM, John Burwell <jb...@basho.com> wrote:
> Marcus,
>
> To my mind, it does not seem appropriate for developers to be making
> release decisions at commit time. Instead, it feels more appropriate to me
> that these decisions are captured in a ticket that is referenced from the
> commit message. This separation allows the PMO/release management
> team/community to determine release contents based on the results of review
> (via Review Board) and testing. If you feel your change is a high priority
> and should be in the next release, you would capture that in the ticket.
> The PMO/release management team/community can then review that decision
> and comment/adjust as necessary. A commit message does not permit this
> type of collaboration. This separation also seems make the creation of
> release notes more straightforward as well.
>
> Thanks,
> -John
>
> On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com> wrote:
>
> > Really I just want to make sure that a commit I make that I know needs to
> > be pushed into the next 4.0 bugfix release gets there. Since someone else
> > is in charge of maintaining 4.0 and merging bug fixes, I can't do it
> > myself, and I'm not really sure how it works now. For example, does that
> > maintainer look through a JIRA report and only merge bugfixes listed
> there?
> >
> >
> > On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <ro...@citrix.com>
> wrote:
> >
> >> I'm not sure how (cherry picking, pull based on commit message) this
> will
> >> work, but it's good idea to mark the commit with some tag with say
> branch
> >> so we always commit on master?
> >> (Bugfix-for or Branch: <branches> )
> >> Branch: 4.0, master #(comma separated branch names).
> >> Bug-id: CLOUDSTACK-xxx
> >>
> >> This may be ambiguous, says some developer did not know if some commit
> >> would apply for some branch? Another issue is to encourage everyone of
> us
> >> to use this convention.
> >> If we could solve it, that would be great.
> >>
> >> ________________________________________
> >> From: Marcus Sorensen [shadowsor@gmail.com]
> >> Sent: Wednesday, November 07, 2012 8:56 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: Rant: Request for better commit messages
> >>
> >> Should we add a line to this commit message, where people can mark
> whether
> >> this patch should be considered for the next bugfix release? Or is that
> all
> >> handled/tracked through JIRA or some other means? I just thought it
> would
> >> be nice for the guy maintaining a release to be able to eventually pull
> in
> >> stuff based on the commit messages. It also allows the committers to
> give
> >> some sort of indication that commit X is important and needs to go into
> the
> >> bugfix.
> >>
> >> For now I'm just adding "Bugfix-for: 4.0" to my commits.
> >>
> >>
> >> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadowsor@gmail.com
> >>> wrote:
> >>
> >>> Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
> >>>
> >>> set it up by running the following from your incubator-cloudstack dir:
> >>>
> >>> 'ln -s ../../tools/git/prepare-commit-msg
> .git/hooks/prepare-commit-msg'
> >>>
> >>> Developers can also optionally commit different prepare-commit-msg
> >>> scripts for each branch, and the link will point to the one you're on.
> >>>
> >>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
> >>> wrote:
> >>>>
> >>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com>
> >> wrote:
> >>>>
> >>>>> I'm by no means a git guru, but in searching around it didn't seem
> >> like
> >>>>> there was a way to enforce the application of hooks from the repo
> >> side.
> >>>>> I'm not sure we'd want to anyway. I was just going to commit the file
> >>> and
> >>>>> then add instructions on the wiki for people to add it in their local
> >>> repo
> >>>>> config.
> >>>>
> >>>> I think that's fine. Instead of hooks what people can do is add a
> >> commit
> >>> template to their local git configuration.
> >>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> >>>>
> >>>> Checkout commit.template, add following to your ~/.gitconfig:
> >>>> [commit]
> >>>> template = ~/.gitmessage
> >>>>
> >>>> And create a ~/.gitmessage like:
> >>>> #Header: one line explaination
> >>>> #
> >>>> #Body of commit message explaining things in more detail, possibly
> >>> giving some
> >>>> #background about the issue being fixed, etc. Maybe use bullets:
> >>>> # - Write in present tense
> >>>> # - Keep text width of commit message within 80 characters.
> >>>> #
> >>>> #Use more than one paragraphs, that's is fine.
> >>>> #
> >>>> #Reviewed-by: Person or link to review on review.apache.org
> >>>> #Reported-by: whoever-reported-it, if applicable
> >>>> #Signed-off-by: Your Name <yo...@yourhost.com>
> >>>>
> >>>> Now every time one does git commit, she will see this in their editor
> >>> and use this as a reminder to write better commit message.
> >>>> For example my:
> >>>> gitconfig:
> >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> >>>> gitmessage:
> >>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> >>>>
> >>>> Regards.
> >>>>
> >>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
> >> wrote:
> >>>>>
> >>>>>>
> >>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Sure thing. A few questions:
> >>>>>>>
> >>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
> >>>>>>> simply "Bug id:"?
> >>>>>>
> >>>>>> I guess as there are already several commits that follow
> >>> CLOUDSTACK-BUGID
> >>>>>> convention, we should continue that.
> >>>>>> Also, there are commits with bug id's of old jira, like CS-16414
> etc.
> >>>>>>
> >>>>>>> I'm assuming that if the commit is a bug fix, the
> >>>>>>> fix will already be described in the summary and detail of the
> >> commit.
> >>>>>>> Or are we looking for something else here other than a description?
> >> I
> >>>>>>> could just see this being redundant, but perhaps I don't understand
> >>>>>>> what's being asked for on that line. Should id describe the bug
> >> itself
> >>>>>>> in one line, rather than the bug fix?
> >>>>>>
> >>>>>> Whatever makes sense, I usually write what that commit does in one
> >>> line.
> >>>>>>
> >>>>>>>
> >>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
> >> message.
> >>>>>>> I realize that some people will have their own configs that already
> >> do
> >>>>>>> this, or be used to using -s to auto-add it to the message, but
> >>>>>>> judging by the logs it seems that the majority don't. So hopefully
> >>>>>>> this doesn't upset anyone horribly :-) They can always change their
> >>>>>>> copy since the hook will need to be manually installed.
> >>>>>>
> >>>>>> I've just put up bunch of guidelines on the wiki, let's take
> whatever
> >>>>>> seems good and follow whatever makes sense.
> >>>>>> My whole intension was to bring up the issue that a short commit
> >>> message
> >>>>>> makes it hard for folks to follow commits.
> >>>>>>
> >>>>>>> Attached is an example commit message generated by the hook so far.
> >>>>>>
> >>>>>> Cool, I guess you would have to contact someone from ASF infra to
> set
> >>> this
> >>>>>> up.
> >>>>>>
> >>>>>>> I
> >>>>>>> left in the default comment message as well, simply because it
> >>>>>>> includes a list of what's modified,etc for reference when typing up
> >>>>>>> the notes.
> >>>>>>
> >>>>>> --
> >>>>>> Rohit
> >>>>>>
> >>>>>>>
> >>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
> >> rohit.yadav@citrix.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> >>>>>>>>
> >>>>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> >>>>>>>>
> >>>>>>>> Pl. check and edit as needed.
> >>>>>>>>
> >>>>>>>> One more thing, I checked looks like ASF infra guys have upgraded
> >>> their
> >>>>>> review board.
> >>>>>>>> The bug (
> >>>>>>
> >>>
> >>
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> >>> )
> >>>>>> got fixed so now downloading the diff downloads the actual uploaded
> >> git
> >>>>>> formatted patch.
> >>>>>>>>
> >>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Might be cool if we could make/document git hooks for a standard
> >>>>>> message form.
> >>>>>>>>
> >>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> >>> repo
> >>>>>> that would be great.
> >>>>>>>>
> >>>>>>>> Regards.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
> >> wido@widodh.nl
> >>>>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Perhaps we could document this on the wiki, as part of a
> nascent
> >>>>>> coding
> >>>>>>>>>>> standards policy?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I'd say so. We already have a coding convention, it's just a
> >> small
> >>>>>> step to
> >>>>>>>>>> add a commit convention.
> >>>>>>>>>>
> >>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> >>>>>>>>>>
> >>>>>>>>>> Wido
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> >>> rohit.yadav@citrix.com
> >>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> With due respect, I would like to request all the committers
> >> and
> >>>>>>>>>>>> contributors to write better commit message. [0]
> >>>>>>>>>>>>
> >>>>>>>>>>>> For example, a good commit message:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> >>>>>>>>>>>>
> >>>>>>>>>>>> A good commit message subject should have something like this
> >>> with
> >>>>>> 80
> >>>>>>>>>>>> chars width:
> >>>>>>>>>>>> <Header line>: <short log description>
> >>>>>>>>>>>> <blank line>
> >>>>>>>>>>>> <body of commit message, explain things why, what, how, etc.
> >>> giving
> >>>>>>>>>>>> background>
> >>>>>>>>>>>> <bulleted points help>
> >>>>>>>>>>>> <blank line>
> >>>>>>>>>>>> <Reported-by: if it's a bug>
> >>>>>>>>>>>> <Reviewed-by: if it was reviewed>
> >>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is what we follow on
> >>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are
> >> crazy
> >>>>>> about
> >>>>>>>>>>>> commits and patches, they just don't accept junk
> >>>>>>>>>>>> messages, even if code is fine. You may check, there is no or
> >> few
> >>>>>>>>>>>> reverts.
> >>>>>>>>>>>>
> >>>>>>>>>>>> When something breaks, I check all last commits and do a git
> >> log
> >>> -p
> >>>>>>>>>>>> <file>
> >>>>>>>>>>>> to go through recent changes to a file, in case I think
> >> something
> >>>>>> broke I
> >>>>>>>>>>>> like to identify the changes that may have caused it instead
> of
> >>>>>> fixing it
> >>>>>>>>>>>> which may introduce further problems. I use tig and zsh to
> >>> regularly
> >>>>>>>>>>>> follow
> >>>>>>>>>>>> commits and read commit messages.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
> >>>>>>>>>>>>
> >>>>>>>>>>>> [0]
> >> https://github.com/torvalds/subsurface/blob/master/README(at
> >>>>>> the
> >>>>>>>>>>>> end)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards.
> >>>>>>>>>>>> PS. I had to email about it as we're uncool with our git
> commit
> >>>>>> habits,
> >>>>>>>>>>>> we
> >>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix our
> >> habits.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>> <examplecommitmsg.txt>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>
>
Re: Rant: Request for better commit messages
Posted by John Burwell <jb...@basho.com>.
Marcus,
To my mind, it does not seem appropriate for developers to be making release decisions at commit time. Instead, it feels more appropriate to me that these decisions are captured in a ticket that is referenced from the commit message. This separation allows the PMO/release management team/community to determine release contents based on the results of review (via Review Board) and testing. If you feel your change is a high priority and should be in the next release, you would capture that in the ticket. The PMO/release management team/community can then review that decision and comment/adjust as necessary. A commit message does not permit this type of collaboration. This separation also seems make the creation of release notes more straightforward as well.
Thanks,
-John
On Nov 7, 2012, at 1:16 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> Really I just want to make sure that a commit I make that I know needs to
> be pushed into the next 4.0 bugfix release gets there. Since someone else
> is in charge of maintaining 4.0 and merging bug fixes, I can't do it
> myself, and I'm not really sure how it works now. For example, does that
> maintainer look through a JIRA report and only merge bugfixes listed there?
>
>
> On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <ro...@citrix.com> wrote:
>
>> I'm not sure how (cherry picking, pull based on commit message) this will
>> work, but it's good idea to mark the commit with some tag with say branch
>> so we always commit on master?
>> (Bugfix-for or Branch: <branches> )
>> Branch: 4.0, master #(comma separated branch names).
>> Bug-id: CLOUDSTACK-xxx
>>
>> This may be ambiguous, says some developer did not know if some commit
>> would apply for some branch? Another issue is to encourage everyone of us
>> to use this convention.
>> If we could solve it, that would be great.
>>
>> ________________________________________
>> From: Marcus Sorensen [shadowsor@gmail.com]
>> Sent: Wednesday, November 07, 2012 8:56 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Rant: Request for better commit messages
>>
>> Should we add a line to this commit message, where people can mark whether
>> this patch should be considered for the next bugfix release? Or is that all
>> handled/tracked through JIRA or some other means? I just thought it would
>> be nice for the guy maintaining a release to be able to eventually pull in
>> stuff based on the commit messages. It also allows the committers to give
>> some sort of indication that commit X is important and needs to go into the
>> bugfix.
>>
>> For now I'm just adding "Bugfix-for: 4.0" to my commits.
>>
>>
>> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadowsor@gmail.com
>>> wrote:
>>
>>> Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
>>>
>>> set it up by running the following from your incubator-cloudstack dir:
>>>
>>> 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg'
>>>
>>> Developers can also optionally commit different prepare-commit-msg
>>> scripts for each branch, and the link will point to the one you're on.
>>>
>>> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
>>> wrote:
>>>>
>>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com>
>> wrote:
>>>>
>>>>> I'm by no means a git guru, but in searching around it didn't seem
>> like
>>>>> there was a way to enforce the application of hooks from the repo
>> side.
>>>>> I'm not sure we'd want to anyway. I was just going to commit the file
>>> and
>>>>> then add instructions on the wiki for people to add it in their local
>>> repo
>>>>> config.
>>>>
>>>> I think that's fine. Instead of hooks what people can do is add a
>> commit
>>> template to their local git configuration.
>>>> http://git-scm.com/book/en/Customizing-Git-Git-Configuration
>>>>
>>>> Checkout commit.template, add following to your ~/.gitconfig:
>>>> [commit]
>>>> template = ~/.gitmessage
>>>>
>>>> And create a ~/.gitmessage like:
>>>> #Header: one line explaination
>>>> #
>>>> #Body of commit message explaining things in more detail, possibly
>>> giving some
>>>> #background about the issue being fixed, etc. Maybe use bullets:
>>>> # - Write in present tense
>>>> # - Keep text width of commit message within 80 characters.
>>>> #
>>>> #Use more than one paragraphs, that's is fine.
>>>> #
>>>> #Reviewed-by: Person or link to review on review.apache.org
>>>> #Reported-by: whoever-reported-it, if applicable
>>>> #Signed-off-by: Your Name <yo...@yourhost.com>
>>>>
>>>> Now every time one does git commit, she will see this in their editor
>>> and use this as a reminder to write better commit message.
>>>> For example my:
>>>> gitconfig:
>>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
>>>> gitmessage:
>>> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
>>>>
>>>> Regards.
>>>>
>>>>> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
>> wrote:
>>>>>
>>>>>>
>>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> Sure thing. A few questions:
>>>>>>>
>>>>>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
>>>>>>> simply "Bug id:"?
>>>>>>
>>>>>> I guess as there are already several commits that follow
>>> CLOUDSTACK-BUGID
>>>>>> convention, we should continue that.
>>>>>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
>>>>>>
>>>>>>> I'm assuming that if the commit is a bug fix, the
>>>>>>> fix will already be described in the summary and detail of the
>> commit.
>>>>>>> Or are we looking for something else here other than a description?
>> I
>>>>>>> could just see this being redundant, but perhaps I don't understand
>>>>>>> what's being asked for on that line. Should id describe the bug
>> itself
>>>>>>> in one line, rather than the bug fix?
>>>>>>
>>>>>> Whatever makes sense, I usually write what that commit does in one
>>> line.
>>>>>>
>>>>>>>
>>>>>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
>> message.
>>>>>>> I realize that some people will have their own configs that already
>> do
>>>>>>> this, or be used to using -s to auto-add it to the message, but
>>>>>>> judging by the logs it seems that the majority don't. So hopefully
>>>>>>> this doesn't upset anyone horribly :-) They can always change their
>>>>>>> copy since the hook will need to be manually installed.
>>>>>>
>>>>>> I've just put up bunch of guidelines on the wiki, let's take whatever
>>>>>> seems good and follow whatever makes sense.
>>>>>> My whole intension was to bring up the issue that a short commit
>>> message
>>>>>> makes it hard for folks to follow commits.
>>>>>>
>>>>>>> Attached is an example commit message generated by the hook so far.
>>>>>>
>>>>>> Cool, I guess you would have to contact someone from ASF infra to set
>>> this
>>>>>> up.
>>>>>>
>>>>>>> I
>>>>>>> left in the default comment message as well, simply because it
>>>>>>> includes a list of what's modified,etc for reference when typing up
>>>>>>> the notes.
>>>>>>
>>>>>> --
>>>>>> Rohit
>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
>> rohit.yadav@citrix.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
>>>>>>>>
>>>>>>
>>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
>>>>>>>>
>>>>>>>> Pl. check and edit as needed.
>>>>>>>>
>>>>>>>> One more thing, I checked looks like ASF infra guys have upgraded
>>> their
>>>>>> review board.
>>>>>>>> The bug (
>>>>>>
>>>
>> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
>>> )
>>>>>> got fixed so now downloading the diff downloads the actual uploaded
>> git
>>>>>> formatted patch.
>>>>>>>>
>>>>>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Might be cool if we could make/document git hooks for a standard
>>>>>> message form.
>>>>>>>>
>>>>>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
>>> repo
>>>>>> that would be great.
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
>> wido@widodh.nl
>>>>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
>>>>>>>>>>>
>>>>>>>>>>> Perhaps we could document this on the wiki, as part of a nascent
>>>>>> coding
>>>>>>>>>>> standards policy?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd say so. We already have a coding convention, it's just a
>> small
>>>>>> step to
>>>>>>>>>> add a commit convention.
>>>>>>>>>>
>>>>>>>>>> I personally like 'clean' GIT repos with clear commit messages.
>>>>>>>>>>
>>>>>>>>>> Wido
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
>>> rohit.yadav@citrix.com
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi folks,
>>>>>>>>>>>>
>>>>>>>>>>>> With due respect, I would like to request all the committers
>> and
>>>>>>>>>>>> contributors to write better commit message. [0]
>>>>>>>>>>>>
>>>>>>>>>>>> For example, a good commit message:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
>>>>>>>>>>>>
>>>>>>>>>>>> A good commit message subject should have something like this
>>> with
>>>>>> 80
>>>>>>>>>>>> chars width:
>>>>>>>>>>>> <Header line>: <short log description>
>>>>>>>>>>>> <blank line>
>>>>>>>>>>>> <body of commit message, explain things why, what, how, etc.
>>> giving
>>>>>>>>>>>> background>
>>>>>>>>>>>> <bulleted points help>
>>>>>>>>>>>> <blank line>
>>>>>>>>>>>> <Reported-by: if it's a bug>
>>>>>>>>>>>> <Reviewed-by: if it was reviewed>
>>>>>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
>>>>>>>>>>>>
>>>>>>>>>>>> This is what we follow on
>>>>>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are
>> crazy
>>>>>> about
>>>>>>>>>>>> commits and patches, they just don't accept junk
>>>>>>>>>>>> messages, even if code is fine. You may check, there is no or
>> few
>>>>>>>>>>>> reverts.
>>>>>>>>>>>>
>>>>>>>>>>>> When something breaks, I check all last commits and do a git
>> log
>>> -p
>>>>>>>>>>>> <file>
>>>>>>>>>>>> to go through recent changes to a file, in case I think
>> something
>>>>>> broke I
>>>>>>>>>>>> like to identify the changes that may have caused it instead of
>>>>>> fixing it
>>>>>>>>>>>> which may introduce further problems. I use tig and zsh to
>>> regularly
>>>>>>>>>>>> follow
>>>>>>>>>>>> commits and read commit messages.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, please fix your editors and follow coding conventions.
>>>>>>>>>>>>
>>>>>>>>>>>> [0]
>> https://github.com/torvalds/subsurface/blob/master/README(at
>>>>>> the
>>>>>>>>>>>> end)
>>>>>>>>>>>>
>>>>>>>>>>>> Regards.
>>>>>>>>>>>> PS. I had to email about it as we're uncool with our git commit
>>>>>> habits,
>>>>>>>>>>>> we
>>>>>>>>>>>> are doing triple or quadruple reverts, we need to fix our
>> habits.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>> <examplecommitmsg.txt>
>>>>>>
>>>>>>
>>>>
>>>
>>
RE: Rant: Request for better commit messages
Posted by Rohit Yadav <ro...@citrix.com>.
I don't know either, let's ask our release manager? Chip, Alex?
Probably a lot of manual checking, it should a committer's responsibility to make sure a patch he's committed gets to all necessary branches.
In case of release, they should inform the release manager, either via commit tags or explicitly over email, that should do right?
________________________________________
From: Marcus Sorensen [shadowsor@gmail.com]
Sent: Wednesday, November 07, 2012 11:46 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Rant: Request for better commit messages
Really I just want to make sure that a commit I make that I know needs to
be pushed into the next 4.0 bugfix release gets there. Since someone else
is in charge of maintaining 4.0 and merging bug fixes, I can't do it
myself, and I'm not really sure how it works now. For example, does that
maintainer look through a JIRA report and only merge bugfixes listed there?
On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <ro...@citrix.com> wrote:
> I'm not sure how (cherry picking, pull based on commit message) this will
> work, but it's good idea to mark the commit with some tag with say branch
> so we always commit on master?
> (Bugfix-for or Branch: <branches> )
> Branch: 4.0, master #(comma separated branch names).
> Bug-id: CLOUDSTACK-xxx
>
> This may be ambiguous, says some developer did not know if some commit
> would apply for some branch? Another issue is to encourage everyone of us
> to use this convention.
> If we could solve it, that would be great.
>
> ________________________________________
> From: Marcus Sorensen [shadowsor@gmail.com]
> Sent: Wednesday, November 07, 2012 8:56 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Rant: Request for better commit messages
>
> Should we add a line to this commit message, where people can mark whether
> this patch should be considered for the next bugfix release? Or is that all
> handled/tracked through JIRA or some other means? I just thought it would
> be nice for the guy maintaining a release to be able to eventually pull in
> stuff based on the commit messages. It also allows the committers to give
> some sort of indication that commit X is important and needs to go into the
> bugfix.
>
> For now I'm just adding "Bugfix-for: 4.0" to my commits.
>
>
> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
>
> > Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
> >
> > set it up by running the following from your incubator-cloudstack dir:
> >
> > 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg'
> >
> > Developers can also optionally commit different prepare-commit-msg
> > scripts for each branch, and the link will point to the one you're on.
> >
> > On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
> > wrote:
> > >
> > > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > >
> > >> I'm by no means a git guru, but in searching around it didn't seem
> like
> > >> there was a way to enforce the application of hooks from the repo
> side.
> > >> I'm not sure we'd want to anyway. I was just going to commit the file
> > and
> > >> then add instructions on the wiki for people to add it in their local
> > repo
> > >> config.
> > >
> > > I think that's fine. Instead of hooks what people can do is add a
> commit
> > template to their local git configuration.
> > > http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> > >
> > > Checkout commit.template, add following to your ~/.gitconfig:
> > > [commit]
> > > template = ~/.gitmessage
> > >
> > > And create a ~/.gitmessage like:
> > > #Header: one line explaination
> > > #
> > > #Body of commit message explaining things in more detail, possibly
> > giving some
> > > #background about the issue being fixed, etc. Maybe use bullets:
> > > # - Write in present tense
> > > # - Keep text width of commit message within 80 characters.
> > > #
> > > #Use more than one paragraphs, that's is fine.
> > > #
> > > #Reviewed-by: Person or link to review on review.apache.org
> > > #Reported-by: whoever-reported-it, if applicable
> > > #Signed-off-by: Your Name <yo...@yourhost.com>
> > >
> > > Now every time one does git commit, she will see this in their editor
> > and use this as a reminder to write better commit message.
> > > For example my:
> > > gitconfig:
> > https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > > gitmessage:
> > https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> > >
> > > Regards.
> > >
> > >> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
> wrote:
> > >>
> > >>>
> > >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
> > wrote:
> > >>>
> > >>>> Sure thing. A few questions:
> > >>>>
> > >>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
> > >>>> simply "Bug id:"?
> > >>>
> > >>> I guess as there are already several commits that follow
> > CLOUDSTACK-BUGID
> > >>> convention, we should continue that.
> > >>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
> > >>>
> > >>>> I'm assuming that if the commit is a bug fix, the
> > >>>> fix will already be described in the summary and detail of the
> commit.
> > >>>> Or are we looking for something else here other than a description?
> I
> > >>>> could just see this being redundant, but perhaps I don't understand
> > >>>> what's being asked for on that line. Should id describe the bug
> itself
> > >>>> in one line, rather than the bug fix?
> > >>>
> > >>> Whatever makes sense, I usually write what that commit does in one
> > line.
> > >>>
> > >>>>
> > >>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
> message.
> > >>>> I realize that some people will have their own configs that already
> do
> > >>>> this, or be used to using -s to auto-add it to the message, but
> > >>>> judging by the logs it seems that the majority don't. So hopefully
> > >>>> this doesn't upset anyone horribly :-) They can always change their
> > >>>> copy since the hook will need to be manually installed.
> > >>>
> > >>> I've just put up bunch of guidelines on the wiki, let's take whatever
> > >>> seems good and follow whatever makes sense.
> > >>> My whole intension was to bring up the issue that a short commit
> > message
> > >>> makes it hard for folks to follow commits.
> > >>>
> > >>>> Attached is an example commit message generated by the hook so far.
> > >>>
> > >>> Cool, I guess you would have to contact someone from ASF infra to set
> > this
> > >>> up.
> > >>>
> > >>>> I
> > >>>> left in the default comment message as well, simply because it
> > >>>> includes a list of what's modified,etc for reference when typing up
> > >>>> the notes.
> > >>>
> > >>> --
> > >>> Rohit
> > >>>
> > >>>>
> > >>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
> rohit.yadav@citrix.com>
> > >>> wrote:
> > >>>>>
> > >>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> > >>>>>
> > >>>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> > >>>>>
> > >>>>> Pl. check and edit as needed.
> > >>>>>
> > >>>>> One more thing, I checked looks like ASF infra guys have upgraded
> > their
> > >>> review board.
> > >>>>> The bug (
> > >>>
> >
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> > )
> > >>> got fixed so now downloading the diff downloads the actual uploaded
> git
> > >>> formatted patch.
> > >>>>>
> > >>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Might be cool if we could make/document git hooks for a standard
> > >>> message form.
> > >>>>>
> > >>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> > repo
> > >>> that would be great.
> > >>>>>
> > >>>>> Regards.
> > >>>>>
> > >>>>>>
> > >>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
> wido@widodh.nl
> > >
> > >>> wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> > >>>>>>>>
> > >>>>>>>> Perhaps we could document this on the wiki, as part of a nascent
> > >>> coding
> > >>>>>>>> standards policy?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> I'd say so. We already have a coding convention, it's just a
> small
> > >>> step to
> > >>>>>>> add a commit convention.
> > >>>>>>>
> > >>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> > >>>>>>>
> > >>>>>>> Wido
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> > rohit.yadav@citrix.com
> > >>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi folks,
> > >>>>>>>>>
> > >>>>>>>>> With due respect, I would like to request all the committers
> and
> > >>>>>>>>> contributors to write better commit message. [0]
> > >>>>>>>>>
> > >>>>>>>>> For example, a good commit message:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> > >>>>>>>>>
> > >>>>>>>>> A good commit message subject should have something like this
> > with
> > >>> 80
> > >>>>>>>>> chars width:
> > >>>>>>>>> <Header line>: <short log description>
> > >>>>>>>>> <blank line>
> > >>>>>>>>> <body of commit message, explain things why, what, how, etc.
> > giving
> > >>>>>>>>> background>
> > >>>>>>>>> <bulleted points help>
> > >>>>>>>>> <blank line>
> > >>>>>>>>> <Reported-by: if it's a bug>
> > >>>>>>>>> <Reviewed-by: if it was reviewed>
> > >>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> > >>>>>>>>>
> > >>>>>>>>> This is what we follow on
> > >>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are
> crazy
> > >>> about
> > >>>>>>>>> commits and patches, they just don't accept junk
> > >>>>>>>>> messages, even if code is fine. You may check, there is no or
> few
> > >>>>>>>>> reverts.
> > >>>>>>>>>
> > >>>>>>>>> When something breaks, I check all last commits and do a git
> log
> > -p
> > >>>>>>>>> <file>
> > >>>>>>>>> to go through recent changes to a file, in case I think
> something
> > >>> broke I
> > >>>>>>>>> like to identify the changes that may have caused it instead of
> > >>> fixing it
> > >>>>>>>>> which may introduce further problems. I use tig and zsh to
> > regularly
> > >>>>>>>>> follow
> > >>>>>>>>> commits and read commit messages.
> > >>>>>>>>>
> > >>>>>>>>> Also, please fix your editors and follow coding conventions.
> > >>>>>>>>>
> > >>>>>>>>> [0]
> https://github.com/torvalds/subsurface/blob/master/README(at
> > >>> the
> > >>>>>>>>> end)
> > >>>>>>>>>
> > >>>>>>>>> Regards.
> > >>>>>>>>> PS. I had to email about it as we're uncool with our git commit
> > >>> habits,
> > >>>>>>>>> we
> > >>>>>>>>> are doing triple or quadruple reverts, we need to fix our
> habits.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>> <examplecommitmsg.txt>
> > >>>
> > >>>
> > >
> >
>
Re: Rant: Request for better commit messages
Posted by Marcus Sorensen <sh...@gmail.com>.
Really I just want to make sure that a commit I make that I know needs to
be pushed into the next 4.0 bugfix release gets there. Since someone else
is in charge of maintaining 4.0 and merging bug fixes, I can't do it
myself, and I'm not really sure how it works now. For example, does that
maintainer look through a JIRA report and only merge bugfixes listed there?
On Wed, Nov 7, 2012 at 11:03 AM, Rohit Yadav <ro...@citrix.com> wrote:
> I'm not sure how (cherry picking, pull based on commit message) this will
> work, but it's good idea to mark the commit with some tag with say branch
> so we always commit on master?
> (Bugfix-for or Branch: <branches> )
> Branch: 4.0, master #(comma separated branch names).
> Bug-id: CLOUDSTACK-xxx
>
> This may be ambiguous, says some developer did not know if some commit
> would apply for some branch? Another issue is to encourage everyone of us
> to use this convention.
> If we could solve it, that would be great.
>
> ________________________________________
> From: Marcus Sorensen [shadowsor@gmail.com]
> Sent: Wednesday, November 07, 2012 8:56 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Rant: Request for better commit messages
>
> Should we add a line to this commit message, where people can mark whether
> this patch should be considered for the next bugfix release? Or is that all
> handled/tracked through JIRA or some other means? I just thought it would
> be nice for the guy maintaining a release to be able to eventually pull in
> stuff based on the commit messages. It also allows the committers to give
> some sort of indication that commit X is important and needs to go into the
> bugfix.
>
> For now I'm just adding "Bugfix-for: 4.0" to my commits.
>
>
> On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
>
> > Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
> >
> > set it up by running the following from your incubator-cloudstack dir:
> >
> > 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg'
> >
> > Developers can also optionally commit different prepare-commit-msg
> > scripts for each branch, and the link will point to the one you're on.
> >
> > On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
> > wrote:
> > >
> > > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > >
> > >> I'm by no means a git guru, but in searching around it didn't seem
> like
> > >> there was a way to enforce the application of hooks from the repo
> side.
> > >> I'm not sure we'd want to anyway. I was just going to commit the file
> > and
> > >> then add instructions on the wiki for people to add it in their local
> > repo
> > >> config.
> > >
> > > I think that's fine. Instead of hooks what people can do is add a
> commit
> > template to their local git configuration.
> > > http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> > >
> > > Checkout commit.template, add following to your ~/.gitconfig:
> > > [commit]
> > > template = ~/.gitmessage
> > >
> > > And create a ~/.gitmessage like:
> > > #Header: one line explaination
> > > #
> > > #Body of commit message explaining things in more detail, possibly
> > giving some
> > > #background about the issue being fixed, etc. Maybe use bullets:
> > > # - Write in present tense
> > > # - Keep text width of commit message within 80 characters.
> > > #
> > > #Use more than one paragraphs, that's is fine.
> > > #
> > > #Reviewed-by: Person or link to review on review.apache.org
> > > #Reported-by: whoever-reported-it, if applicable
> > > #Signed-off-by: Your Name <yo...@yourhost.com>
> > >
> > > Now every time one does git commit, she will see this in their editor
> > and use this as a reminder to write better commit message.
> > > For example my:
> > > gitconfig:
> > https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > > gitmessage:
> > https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> > >
> > > Regards.
> > >
> > >> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com>
> wrote:
> > >>
> > >>>
> > >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
> > wrote:
> > >>>
> > >>>> Sure thing. A few questions:
> > >>>>
> > >>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
> > >>>> simply "Bug id:"?
> > >>>
> > >>> I guess as there are already several commits that follow
> > CLOUDSTACK-BUGID
> > >>> convention, we should continue that.
> > >>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
> > >>>
> > >>>> I'm assuming that if the commit is a bug fix, the
> > >>>> fix will already be described in the summary and detail of the
> commit.
> > >>>> Or are we looking for something else here other than a description?
> I
> > >>>> could just see this being redundant, but perhaps I don't understand
> > >>>> what's being asked for on that line. Should id describe the bug
> itself
> > >>>> in one line, rather than the bug fix?
> > >>>
> > >>> Whatever makes sense, I usually write what that commit does in one
> > line.
> > >>>
> > >>>>
> > >>>> I'm also assuming it's ok to add the "Signed-off-by:" to the
> message.
> > >>>> I realize that some people will have their own configs that already
> do
> > >>>> this, or be used to using -s to auto-add it to the message, but
> > >>>> judging by the logs it seems that the majority don't. So hopefully
> > >>>> this doesn't upset anyone horribly :-) They can always change their
> > >>>> copy since the hook will need to be manually installed.
> > >>>
> > >>> I've just put up bunch of guidelines on the wiki, let's take whatever
> > >>> seems good and follow whatever makes sense.
> > >>> My whole intension was to bring up the issue that a short commit
> > message
> > >>> makes it hard for folks to follow commits.
> > >>>
> > >>>> Attached is an example commit message generated by the hook so far.
> > >>>
> > >>> Cool, I guess you would have to contact someone from ASF infra to set
> > this
> > >>> up.
> > >>>
> > >>>> I
> > >>>> left in the default comment message as well, simply because it
> > >>>> includes a list of what's modified,etc for reference when typing up
> > >>>> the notes.
> > >>>
> > >>> --
> > >>> Rohit
> > >>>
> > >>>>
> > >>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <
> rohit.yadav@citrix.com>
> > >>> wrote:
> > >>>>>
> > >>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> > >>>>>
> > >>>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> > >>>>>
> > >>>>> Pl. check and edit as needed.
> > >>>>>
> > >>>>> One more thing, I checked looks like ASF infra guys have upgraded
> > their
> > >>> review board.
> > >>>>> The bug (
> > >>>
> >
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> > )
> > >>> got fixed so now downloading the diff downloads the actual uploaded
> git
> > >>> formatted patch.
> > >>>>>
> > >>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
> > >>> wrote:
> > >>>>>
> > >>>>>> Might be cool if we could make/document git hooks for a standard
> > >>> message form.
> > >>>>>
> > >>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> > repo
> > >>> that would be great.
> > >>>>>
> > >>>>> Regards.
> > >>>>>
> > >>>>>>
> > >>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <
> wido@widodh.nl
> > >
> > >>> wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> > >>>>>>>>
> > >>>>>>>> Perhaps we could document this on the wiki, as part of a nascent
> > >>> coding
> > >>>>>>>> standards policy?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> I'd say so. We already have a coding convention, it's just a
> small
> > >>> step to
> > >>>>>>> add a commit convention.
> > >>>>>>>
> > >>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> > >>>>>>>
> > >>>>>>> Wido
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> > rohit.yadav@citrix.com
> > >>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi folks,
> > >>>>>>>>>
> > >>>>>>>>> With due respect, I would like to request all the committers
> and
> > >>>>>>>>> contributors to write better commit message. [0]
> > >>>>>>>>>
> > >>>>>>>>> For example, a good commit message:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> > >>>>>>>>>
> > >>>>>>>>> A good commit message subject should have something like this
> > with
> > >>> 80
> > >>>>>>>>> chars width:
> > >>>>>>>>> <Header line>: <short log description>
> > >>>>>>>>> <blank line>
> > >>>>>>>>> <body of commit message, explain things why, what, how, etc.
> > giving
> > >>>>>>>>> background>
> > >>>>>>>>> <bulleted points help>
> > >>>>>>>>> <blank line>
> > >>>>>>>>> <Reported-by: if it's a bug>
> > >>>>>>>>> <Reviewed-by: if it was reviewed>
> > >>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> > >>>>>>>>>
> > >>>>>>>>> This is what we follow on
> > >>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are
> crazy
> > >>> about
> > >>>>>>>>> commits and patches, they just don't accept junk
> > >>>>>>>>> messages, even if code is fine. You may check, there is no or
> few
> > >>>>>>>>> reverts.
> > >>>>>>>>>
> > >>>>>>>>> When something breaks, I check all last commits and do a git
> log
> > -p
> > >>>>>>>>> <file>
> > >>>>>>>>> to go through recent changes to a file, in case I think
> something
> > >>> broke I
> > >>>>>>>>> like to identify the changes that may have caused it instead of
> > >>> fixing it
> > >>>>>>>>> which may introduce further problems. I use tig and zsh to
> > regularly
> > >>>>>>>>> follow
> > >>>>>>>>> commits and read commit messages.
> > >>>>>>>>>
> > >>>>>>>>> Also, please fix your editors and follow coding conventions.
> > >>>>>>>>>
> > >>>>>>>>> [0]
> https://github.com/torvalds/subsurface/blob/master/README(at
> > >>> the
> > >>>>>>>>> end)
> > >>>>>>>>>
> > >>>>>>>>> Regards.
> > >>>>>>>>> PS. I had to email about it as we're uncool with our git commit
> > >>> habits,
> > >>>>>>>>> we
> > >>>>>>>>> are doing triple or quadruple reverts, we need to fix our
> habits.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>> <examplecommitmsg.txt>
> > >>>
> > >>>
> > >
> >
>
RE: Rant: Request for better commit messages
Posted by Rohit Yadav <ro...@citrix.com>.
I'm not sure how (cherry picking, pull based on commit message) this will work, but it's good idea to mark the commit with some tag with say branch so we always commit on master?
(Bugfix-for or Branch: <branches> )
Branch: 4.0, master #(comma separated branch names).
Bug-id: CLOUDSTACK-xxx
This may be ambiguous, says some developer did not know if some commit would apply for some branch? Another issue is to encourage everyone of us to use this convention.
If we could solve it, that would be great.
________________________________________
From: Marcus Sorensen [shadowsor@gmail.com]
Sent: Wednesday, November 07, 2012 8:56 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Rant: Request for better commit messages
Should we add a line to this commit message, where people can mark whether
this patch should be considered for the next bugfix release? Or is that all
handled/tracked through JIRA or some other means? I just thought it would
be nice for the guy maintaining a release to be able to eventually pull in
stuff based on the commit messages. It also allows the committers to give
some sort of indication that commit X is important and needs to go into the
bugfix.
For now I'm just adding "Bugfix-for: 4.0" to my commits.
On Thu, Oct 18, 2012 at 3:59 PM, Marcus Sorensen <sh...@gmail.com>wrote:
> Ok, this is now in master, see 9ba7509c70fe82a8ce0b08826d424de452aef1d2
>
> set it up by running the following from your incubator-cloudstack dir:
>
> 'ln -s ../../tools/git/prepare-commit-msg .git/hooks/prepare-commit-msg'
>
> Developers can also optionally commit different prepare-commit-msg
> scripts for each branch, and the link will point to the one you're on.
>
> On Sun, Oct 14, 2012 at 10:19 AM, Rohit Yadav <ro...@citrix.com>
> wrote:
> >
> > On 14-Oct-2012, at 9:18 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> >
> >> I'm by no means a git guru, but in searching around it didn't seem like
> >> there was a way to enforce the application of hooks from the repo side.
> >> I'm not sure we'd want to anyway. I was just going to commit the file
> and
> >> then add instructions on the wiki for people to add it in their local
> repo
> >> config.
> >
> > I think that's fine. Instead of hooks what people can do is add a commit
> template to their local git configuration.
> > http://git-scm.com/book/en/Customizing-Git-Git-Configuration
> >
> > Checkout commit.template, add following to your ~/.gitconfig:
> > [commit]
> > template = ~/.gitmessage
> >
> > And create a ~/.gitmessage like:
> > #Header: one line explaination
> > #
> > #Body of commit message explaining things in more detail, possibly
> giving some
> > #background about the issue being fixed, etc. Maybe use bullets:
> > # - Write in present tense
> > # - Keep text width of commit message within 80 characters.
> > #
> > #Use more than one paragraphs, that's is fine.
> > #
> > #Reviewed-by: Person or link to review on review.apache.org
> > #Reported-by: whoever-reported-it, if applicable
> > #Signed-off-by: Your Name <yo...@yourhost.com>
> >
> > Now every time one does git commit, she will see this in their editor
> and use this as a reminder to write better commit message.
> > For example my:
> > gitconfig:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig
> > gitmessage:
> https://github.com/bhaisaab/dotfiles/blob/master/git/gitmessage
> >
> > Regards.
> >
> >> On Oct 14, 2012 4:07 AM, "Rohit Yadav" <ro...@citrix.com> wrote:
> >>
> >>>
> >>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> >>>
> >>>> Sure thing. A few questions:
> >>>>
> >>>> the "CLOUDSTACK-<BUGID> prefix:" line, should that be changed to
> >>>> simply "Bug id:"?
> >>>
> >>> I guess as there are already several commits that follow
> CLOUDSTACK-BUGID
> >>> convention, we should continue that.
> >>> Also, there are commits with bug id's of old jira, like CS-16414 etc.
> >>>
> >>>> I'm assuming that if the commit is a bug fix, the
> >>>> fix will already be described in the summary and detail of the commit.
> >>>> Or are we looking for something else here other than a description? I
> >>>> could just see this being redundant, but perhaps I don't understand
> >>>> what's being asked for on that line. Should id describe the bug itself
> >>>> in one line, rather than the bug fix?
> >>>
> >>> Whatever makes sense, I usually write what that commit does in one
> line.
> >>>
> >>>>
> >>>> I'm also assuming it's ok to add the "Signed-off-by:" to the message.
> >>>> I realize that some people will have their own configs that already do
> >>>> this, or be used to using -s to auto-add it to the message, but
> >>>> judging by the logs it seems that the majority don't. So hopefully
> >>>> this doesn't upset anyone horribly :-) They can always change their
> >>>> copy since the hook will need to be manually installed.
> >>>
> >>> I've just put up bunch of guidelines on the wiki, let's take whatever
> >>> seems good and follow whatever makes sense.
> >>> My whole intension was to bring up the issue that a short commit
> message
> >>> makes it hard for folks to follow commits.
> >>>
> >>>> Attached is an example commit message generated by the hook so far.
> >>>
> >>> Cool, I guess you would have to contact someone from ASF infra to set
> this
> >>> up.
> >>>
> >>>> I
> >>>> left in the default comment message as well, simply because it
> >>>> includes a list of what's modified,etc for reference when typing up
> >>>> the notes.
> >>>
> >>> --
> >>> Rohit
> >>>
> >>>>
> >>>> On Fri, Oct 12, 2012 at 2:56 AM, Rohit Yadav <ro...@citrix.com>
> >>> wrote:
> >>>>>
> >>>>> I ported an old wiki from wiki.cloudstack to cwiki.a.o
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
> >>>>>
> >>>>> Pl. check and edit as needed.
> >>>>>
> >>>>> One more thing, I checked looks like ASF infra guys have upgraded
> their
> >>> review board.
> >>>>> The bug (
> >>>
> http://code.google.com/p/reviewboard/issues/detail?id=2690&thanks=2690&ts=1343826104
> )
> >>> got fixed so now downloading the diff downloads the actual uploaded git
> >>> formatted patch.
> >>>>>
> >>>>> On 12-Oct-2012, at 2:42 AM, Marcus Sorensen <sh...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Might be cool if we could make/document git hooks for a standard
> >>> message form.
> >>>>>
> >>>>> Marcus it's a good idea, pl. check if we can add git hooks to ASF
> repo
> >>> that would be great.
> >>>>>
> >>>>> Regards.
> >>>>>
> >>>>>>
> >>>>>> On Thu, Oct 11, 2012 at 3:05 PM, Wido den Hollander <wido@widodh.nl
> >
> >>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/10/2012 08:50 PM, Noah Slater wrote:
> >>>>>>>>
> >>>>>>>> Perhaps we could document this on the wiki, as part of a nascent
> >>> coding
> >>>>>>>> standards policy?
> >>>>>>>
> >>>>>>>
> >>>>>>> I'd say so. We already have a coding convention, it's just a small
> >>> step to
> >>>>>>> add a commit convention.
> >>>>>>>
> >>>>>>> I personally like 'clean' GIT repos with clear commit messages.
> >>>>>>>
> >>>>>>> Wido
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Oct 10, 2012 at 8:01 AM, Rohit Yadav <
> rohit.yadav@citrix.com
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi folks,
> >>>>>>>>>
> >>>>>>>>> With due respect, I would like to request all the committers and
> >>>>>>>>> contributors to write better commit message. [0]
> >>>>>>>>>
> >>>>>>>>> For example, a good commit message:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=384c03e42578f17432a483d5828aad64175d9c49
> >>>>>>>>>
> >>>>>>>>> A good commit message subject should have something like this
> with
> >>> 80
> >>>>>>>>> chars width:
> >>>>>>>>> <Header line>: <short log description>
> >>>>>>>>> <blank line>
> >>>>>>>>> <body of commit message, explain things why, what, how, etc.
> giving
> >>>>>>>>> background>
> >>>>>>>>> <bulleted points help>
> >>>>>>>>> <blank line>
> >>>>>>>>> <Reported-by: if it's a bug>
> >>>>>>>>> <Reviewed-by: if it was reviewed>
> >>>>>>>>> <Signed-off: turn on signature in your .gitconfig>
> >>>>>>>>>
> >>>>>>>>> This is what we follow on
> >>>>>>>>> http://git.videolan.org/?p=vlmc.git;a=shortlogand they are crazy
> >>> about
> >>>>>>>>> commits and patches, they just don't accept junk
> >>>>>>>>> messages, even if code is fine. You may check, there is no or few
> >>>>>>>>> reverts.
> >>>>>>>>>
> >>>>>>>>> When something breaks, I check all last commits and do a git log
> -p
> >>>>>>>>> <file>
> >>>>>>>>> to go through recent changes to a file, in case I think something
> >>> broke I
> >>>>>>>>> like to identify the changes that may have caused it instead of
> >>> fixing it
> >>>>>>>>> which may introduce further problems. I use tig and zsh to
> regularly
> >>>>>>>>> follow
> >>>>>>>>> commits and read commit messages.
> >>>>>>>>>
> >>>>>>>>> Also, please fix your editors and follow coding conventions.
> >>>>>>>>>
> >>>>>>>>> [0] https://github.com/torvalds/subsurface/blob/master/README(at
> >>> the
> >>>>>>>>> end)
> >>>>>>>>>
> >>>>>>>>> Regards.
> >>>>>>>>> PS. I had to email about it as we're uncool with our git commit
> >>> habits,
> >>>>>>>>> we
> >>>>>>>>> are doing triple or quadruple reverts, we need to fix our habits.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=7bcbae5e91a4cd122d0efa7f2542eab73debb6df
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=c49f3beccfcd1257eca1ea06606fb55b3fdf5093
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=66daa1a2bc6e86adea265a8a0b8b512756c8f77c
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=828fa3389bbe7cd0378c4e55152d671932badca2
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bb7f9ad9774019f4fdb4d72b2e32a36df9c89188
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=75e2a1012fccc01c639c7f41be564ac0e32088fb
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=5078dff6e76649fbc51e2b9c003fd8e03eef18f3
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=850433240401cd318f1d8d8b0fa2032a60d52c1f
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>> <examplecommitmsg.txt>
> >>>
> >>>
> >
>