Hi,
On 21.06.2012 14:10, Jürgen Schmidt wrote:
On 6/21/12 11:47 AM, Herbert Duerr wrote:
[..]
good point and I agree.
That means we use something like
###
<issuenumber> + <1_line_summary/description>
<longer description_on_demand>
<patch_by_on_demand>
...
###
where
<issuenumber> is
- either the plain <number> + ":"
- or #<number>#
- or #i<number>#
I can live with all but we should agree on one notation. My preference
is the first and then the second. I don't think we need the lower case
'i' anymore.
For me in the order of preference I would use:
- #<number># (we have only one tracker, no need for flags like 'i')
- #i<number>#
I would not like plain <number> + ":", it is just too hard to recognize
(also to grep for). Maybe it's years of training, but I can simply
immediately scan if in a task and/or description a Task-ID is included
or not, just because of the #-usages.
Removal of older tokenized values will depend on being able to identify
those reliable 100% which I doubt being possible. I sometimes just enter
a found ID to bugracker, if it does not exist, it's old. If it does
exist, a short look at it normally makes clear if it is related or not
(because it was from another tracker). Inconvenient, but better than
nothing *sigh*.
Older commit messages can be interpreted by knowing the older
conventions and today we have only one bugtracker.
Issues from other bugtracker systems should be ideally duplicated in our
system. The other systems can be public or private bug tracking systems
and issue numbers of the latter ones don't help anybody.
+1
I would like to hear other opinions of people who actually work with our
code.
Juergen
I'm also against using a bare issue number, because having a number that
can be reliably parsed by eventual tools (e.g. a tool that updates
bugzilla with the revision number, a tool that links the revision commit
to the corresponding bug URL, etc.) is no extra effort whereas it opens
a whole world of opportunities. I prefer that computers do such work
that can be automated because they are rather good at that.
fix:<short description/summary>
I like the commit conventions used in the linux kernel. Browse some
"commit" links of the kernel shortlog at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
to see some examples.
A common notation used by all would be of course helpful
+1
Herbert
