On Wed, Nov 7, 2012 at 5:58 PM, Alex Huang <alex.hu...@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...@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:shadow...@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 <jburw...@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 <shadow...@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 >> > > <rohit.ya...@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 [shadow...@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 >> > >> <shadow...@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 >> > >>> <rohit.ya...@citrix.com> >> > >>> wrote: >> > >>>> >> > >>>> On 14-Oct-2012, at 9:18 PM, Marcus Sorensen >> <shadow...@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 <yourem...@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" >> > >>>>> <rohit.ya...@citrix.com> >> > >> wrote: >> > >>>>> >> > >>>>>> >> > >>>>>> On 12-Oct-2012, at 10:29 PM, Marcus Sorensen >> > >>>>>> <shadow...@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.ya...@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 >> > >>>>>>>> <shadow...@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 < >> > >> w...@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.ya...@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> >> > >>>>>> >> > >>>>>> >> > >>>> >> > >>> >> > >> >> > >> > >
