incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: Commit message summaries
Date Thu, 21 Jun 2012 16:22:15 GMT

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.


> 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
>> to see some examples.
>>> A common notation used by all would be of course helpful
>> +1
>> Herbert

View raw message