On Thu, 2010-10-14 at 13:50 +0200, Jan Provaznik wrote:
> On 10/13/2010 05:00 PM, Mark McLoughlin wrote:
> > On Wed, 2010-10-13 at 10:44 -0400, Jason Guiditta wrote:
> >> Hello all, was just chatting with Scott, and wanted to try to get
> >> everyone who is working on BZs to use the same style formatting to make
> >> things a bit easier for making sure the right patches get pulled in for
> >> QE to test. Nothing complex, just want some consistency:
> >> subject line gets 'BZ{#} -regular subject', standard body msg describing
> >> what you have done
> >
> > FWIW, I've found myself doing the following:
> >
> > <short summary>
> >
> > https://bugzilla.redhat.com/XXXXXX
> >
> > <long description>
> >
> > That way you're not limiting the amount of space to describe the commit
> > in the short summary and you have a (fairly concise) clicky-clicky link
> > to the bz.
> >
> >> Also would like to get us all doing the same thing when updating a
> >> status for a bug that we have fixed. If you send a fix to list, but
> >> should be marked POST, and commit hash should be added as a comment.
> >> <Maintainer> will move it to MODIFY once that patch has been ACKed,
> >> built in rpm on our test repo, and pulled into the branch for QE
> >> testing.
> >
> > Sounds good, except I wouldn't use a commit hash unless it refers to the
> > hash of a commit in the upstream repo. A clicky-clicky link into the
> > mailing list archive or gitweb would be more useful.
> >
>
> +1 for not using hash - when there is a push to next between formatting
> and pushing a patch, hash will be different, won't be?
>
> Jan
No, as long as you use git am, the hash will be the same when you push
to public repo. I like including the BZ link though, I have added that
to my process.
-j
_______________________________________________
deltacloud-devel mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/deltacloud-devel
