Yes, and to be clear all but ${task.id} is redundant from the point of view of our
implementation since we generate the matching regexp from whatever you put in
there. The template you are suggesting would be [${task.id}]
${task.description} and the latest
release of Mylar will happily support that. As for what we have now, figuring
that default out involved the usual 50+ comments (on bug 117517) and
here is what we learned:
- Being
compatible with Bugzilla hyperlinking conventions is beneficial (i.e. bug
123 and bug#123). Users are accustomed to seeing these and the
prefix gives the ID meaning, Mylar’s hyperlink detectors link this
pattern whenever they can, and the result is a nice consistency between
the web UI and the rich Eclipse-based UI.
- Being
compatible with less smart tools is also beneficial. When we
experimented with taking the full URL some users screamed because they
could no longer click bugs in CVS commit emails. URLs are a good
lowest-common denominator that many text and web-based tools use (e.g. Fisheye),
so we determined that leaving them was worth the comment bloat, but put
them on a second line.
- The
status is totally redundant, but when scanning incoming change sets and
History view lists this is often the most valuable bit of information.
Opening the corresponding bug takes two clicks with Mylar’s popup
menu action, but the status prefix tells you instantly whether/when the
commit of interest corresponded to an important state change (e.g.
resolved, reopened).
Of course the main thing that we learned
is that there is no ideal default, and that they key thing is for the template
to be easy to customize. But if others have strong opinions about what
the default should be, please let us know here or on the bug linked
above. We would also be happy to make it easy import a default template for
the bugs.eclipse.org repository, for that comment on the following bug (and
note the additional redundancy, and utility, in the output of the Copy Details action
when I pasted this bug into the email ;)
bug 157342: allow commit comment
templates to be set per repository
https://bugs.eclipse.org/bugs/show_bug.cgi?id=157342
Mik
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
Sent: Thursday, November 16, 2006
12:49 PM
To: Cross project
issues; Europa Build
Workshop
Cc: Neil Skrypuch
Subject: Re:
[cross-project-issues-dev] CVS commit conventions / bestpractices/ free
benefits
Thanks everyone, for all
the +1s! I wasn't sure how this evangelical soapbox would be received. ;-)
Mik:
Your commit comment template is certainly valid, and will be parsed by the
current tool, but it's overkill - CVS bloat, if you will. Here's why.
Putting bug status in CVS is not necessary (it's in Bugzilla!), nor is putting
in BOTH the bug # and the bug URL, since the URL contains the bug # and that's
one of the several supported CVS commit comment syntaxes that our tools
support. If your ${ task.description} is
the same as the value in Bugzilla (bug title/summary) then that's redundant
information too - the comment ought to be something more meaningful than the
bug's title, or else nothing. All you need is:
[123456] fixed the foobar doohickey in method baz()
But since Mylar currently doesn't allow for [] wrapping of bug numbers (does
it? your screen shot seems to imply new features I haven't seen the version of
Mylar I use), then the other way to write this would be:
fixed the foobar doohickey in method baz() https://bugs.eclipse.org/bugs/show_bug.cgi?id=123456
or
https://bugs.eclipse.org/bugs/show_bug.cgi?id=123456
fixed the foobar doohickey in method baz()
--
One additional thing not mentioned in the bugs below or my original soap box is
that we also employ a couple other conventions for identifying non-committer
commits (NCCs). One is to use {username}
in the commit comment: http://www.eclipse.org/emf/searchcvs.php?q=author%3Anickb+skrypuch+patch
The other is to provide contributor details in Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=161744#c10
This is useful when you have to concoct your project IP log - you can just
query Bugzilla for "[contrib" to find all your NCCs: https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&classification=Tools&product=EMF&long_desc_type=allwordssubstr&long_desc=%5Bcontrib
Cheers,
Nick
On 11/16/06, Mik Kersten
<beatmik@xxxxxxx> wrote:
+1 for standardizing on this. I *really*
like Release Notes feature.
What is the commit comment convention? I
last recall it being "bug 123", and I want to make sure that Mylar's
default template works for the convention (we use this template for automatic
commit messages and for mapping from History view entries to
bugs/comments). Is it just ensuring that "bug <id>" is
somewhere in the text?
For a bugs.eclipse.org bug the above would resolve to:
RESOLVED - bug 161626: Jumping tasks in workweek
Task List
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161626
Mik
+1. Let's standardize this across Eclipse. With this standardized I can
see cool additions to the team tools coming... (please?)
Lawrence
Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
I
think consistency like this can only be a good thing. Perhaps should
this practice be part of our Open Source Process?
Should there be a blurb about this somewhere here?
http://wiki.eclipse.org/index.php/Development_Resources
Nick Boldt wrote:
> Hey everyone!
>
> In exploring the various conventions people
use when committing
> changes to CVS associated w/ specific
bugzillas, I've discovered that
> there are more than a *DOZEN* ways people
identify bugzillas.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=164719
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=153838
>
> Why does this matter?
>
> Well, suppose there was a tool that could
query both Bugzilla and CVS
> to tell you what files were changed for a
given bug, or who fixed a
> bug, when it was fixed, and see the actual
fixes made (ie., with
> viewcvs diff).
>
> But wait, don't order yet! Just look what
else you get! ;-)
>
> Suppose that a second tool was being built to
generate release notes
> from that database of commit comments and
bugzilla details, using
> nothing more than a simple relationship
between CVS branch
> (R2_2_maintenance), release version (2.2.2),
and buildID
> (S200610121234).
>
> Suppose you're a small project who doesn't
have the manpower to
> statically generate release notes, lists of
changed bugs, and lists of
> files changed by bug, but want to provide
good project management &
> change auditing.
>
> Or maybe you don't care... until you have to
backport something
> between branches, and need to quickly dig up
where you did the change
> in HEAD to apply it to your maintenance
branch, in a file you've
> updated 20 times since. Given only the bug
number, how quickly can
> you find all affected files, and see the
actual deltas?
>
> Or maybe 20 people all commit things
concurrently into a large cvs
> repo and ONE of them committed a typo and now
your build's broken.
> Wouldn't it be handy to know who made the
changes between the last
> good build and the broken one, to be able to
better diagnose where the
> error occurred? Sure, you could generate a
static cvs log, but what if
> you could just query between datestamps (good
build to bad build) for
> a list of commits, including author, bugzilla
(# and link) and actual
> recorded cvs delta (viewcvs)?
>
> Suppose these tools existed as Phoenixized
web pages, and all you had
> to do to get them to work was:
>
> a) adhere to a consistent commit comment
convention (say that 5 times
> fast!)
>
> b) add your cvs repo(s) to the index (really,
that's just `cvs checkout`)
>
> c) provide details about the three-way
mapping (cvs branch : version :
> buildID) on a regular basis, such as with an
RSS feed
>
> Screen shots:
>
> http://wiki.eclipse.org/index.php/Image:Search-cvs.png
> http://wiki.eclipse.org/index.php/Image:Release-notes.png
>
> To try out Search CVS, go here:
>
> http://www.eclipse.org/emf/searchcvs.php
> http://wiki.eclipse.org/index.php/Search_CVS
>
> The Release Notes part is still being
fine-tuned in order to support
> nested projects, but should be live shortly.
>
> If you have any questions or would like to be
added to the index so
> you can see your commits in Search CVS (try
before you buy), drop me a
> line and I'll give you a hand.
>
> Act now, operators are standing by! 8-)
>
> --
> Nick Boldt
:: Release Engineer, IBM Toronto Lab
> Eclipse Modeling :: http://www.eclipse.org/modeling
> http://wiki.eclipse.org/index.php/User:Nickb
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
