You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openoffice.apache.org by wa...@apache.org on 2012/06/20 08:58:36 UTC
svn commit: r1351948 -
/incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx
Author: wangzcdl
Date: Wed Jun 20 06:58:35 2012
New Revision: 1351948
URL: http://svn.apache.org/viewvc?rev=1351948&view=rev
Log:
for #119951#
Modified:
incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx
Modified: incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx
URL: http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx?rev=1351948&r1=1351947&r2=1351948&view=diff
==============================================================================
--- incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx (original)
+++ incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx Wed Jun 20 06:58:35 2012
@@ -3530,15 +3530,7 @@ bool MainSequence::disposeShape( const R
InteractiveSequenceList::iterator aIter;
for( aIter = maInteractiveSequenceList.begin(); aIter != maInteractiveSequenceList.end(); )
{
- if( (*aIter)->getTriggerShape() == xShape )
- {
- aIter = maInteractiveSequenceList.erase( aIter );
- bChanges = true;
- }
- else
- {
bChanges |= (*aIter++)->disposeShape( xShape );
- }
}
if( bChanges )
Re: Commit message summaries
Posted by Andrea Pescetti <pe...@apache.org>.
On 21/06/2012 Herbert Duerr wrote:
> There are more good reason for my suggestion to continue with the
> i-decorated issue number:
> The code base of AOO 3.4.0 already has more than 8000(!!!) code comments
> using the #i123456# convention for referencing issues in bugzilla.
> There are more than 200000 changeset comments in the OOo code history
> which also use this convention.
Even though I rarely commit and browse commit messages, the #i123456#
convention seems more natural to me too. Remember also that now
OpenOffice is sharing a source tree with other ASF project but maintains
its own BugZilla, so the #i123456# convention can be better if some
automatic handling is needed.
Regards,
Andrea.
Re: Commit message summaries
Posted by Herbert Duerr <hd...@apache.org>.
Extending my older mail with some statistical details.
On 21.06.2012 11:47, I wrote:
> 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.
There are more good reason for my suggestion to continue with the
i-decorated issue number:
The code base of AOO 3.4.0 already has more than 8000(!!!) code comments
using the #i123456# convention for referencing issues in bugzilla.
There are more than 200000 changeset comments in the OOo code history
which also use this convention. What other than confusion would we gain
if we abandoned this convention and why should we as the continuation of
the OpenOffice.org project do that?
Interestingly there are about 9000 code comments using the undecorated
issue number for references to the pre-OOo bug tracking system.
Reintroducing undecorated issue numbers again for new commits only adds
uncalled-for confusion. Speaking of the pre-OOo bug tracker system I
think in our code base we should remove the references into it. The
pre-OOo tracker died many years ago and that devalued these references.
Herbert
Re: Commit message summaries
Posted by sebb <se...@gmail.com>.
On 21 June 2012 19:10, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jun 21, 2012 at 8:10 AM, Jürgen Schmidt
> <jo...@googlemail.com> wrote:
>> On 6/21/12 11:47 AM, Herbert Duerr wrote:
>>> On 21.06.2012 10:17, Jürgen Schmidt wrote:
>>>> We have already introduced the Patch by, Review By .. fields for adding
>>>> further information.
>>>>
>>>> How about logs like
>>>>
>>>> ####
>>>> <issuenumber>:<issue subject line>
>>>
>>> I agree that the issue subject line is better than nothing, but I prefer
>>> that the subject line is about why the change was made. See e.g. the six
>>> different changes for issue 118923. Why would anyone want the same
>>> change header for each commit when you can have a description instead
>>> that matches the change much better?
>>
>> 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.
>>
>> Older commit messages can be interpreted by knowing the older
>> conventions and today we have only one bugtracker.
>>
>
> It may also be possible to change a commit message using svn propedit.
> Does anyone know if this is enabled for committer access?
AFAIK, if the login can commit, it can also change the log message;
there's no separate karma needed.
> See: http://subversion.apache.org/faq.html#change-log-msg
>
> This could also be useful for older commits that used a different
> format for "patch by:" acknowledgements.
>
> -Rob
>
>
>> 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
>>>
>>> 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
>>
>>
Re: Commit message summaries
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jun 21, 2012 at 8:10 AM, Jürgen Schmidt
<jo...@googlemail.com> wrote:
> On 6/21/12 11:47 AM, Herbert Duerr wrote:
>> On 21.06.2012 10:17, Jürgen Schmidt wrote:
>>> We have already introduced the Patch by, Review By .. fields for adding
>>> further information.
>>>
>>> How about logs like
>>>
>>> ####
>>> <issuenumber>:<issue subject line>
>>
>> I agree that the issue subject line is better than nothing, but I prefer
>> that the subject line is about why the change was made. See e.g. the six
>> different changes for issue 118923. Why would anyone want the same
>> change header for each commit when you can have a description instead
>> that matches the change much better?
>
> 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.
>
> Older commit messages can be interpreted by knowing the older
> conventions and today we have only one bugtracker.
>
It may also be possible to change a commit message using svn propedit.
Does anyone know if this is enabled for committer access?
See: http://subversion.apache.org/faq.html#change-log-msg
This could also be useful for older commits that used a different
format for "patch by:" acknowledgements.
-Rob
> 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
>>
>> 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
>
>
Re: Commit message summaries
Posted by Pedro Giffuni <pf...@apache.org>.
Hi;
--- Gio 21/6/12, Armin Le Grand <Ar...@me.com> ha scritto:
...
>
> 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).
I personally find the #<bznumber># notation ugly.
I prefer:
i<bznumber> - Short description.
but I also use
_____
Short Description
Long description
Issue: <number>
Author: <name>
Reviewed by: <name2>
Discussed with: <name3>
_____
I actually prefer the last one because the issue number
takes space from the header and we shouldn't need to
check bugzilla to make a good idea of the change.
Of course it's just me and I will adhere to the
notation decided by the project.
Pedro.
Re: Commit message summaries
Posted by Armin Le Grand <Ar...@me.com>.
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
>
>
>
Re: Commit message summaries
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.06.2012 14:10, Jürgen Schmidt wrote:
> On 6/21/12 11:47 AM, Herbert Duerr wrote:
>> On 21.06.2012 10:17, Jürgen Schmidt wrote:
>
> [snip]
>
> 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.
>
> 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.
>
I overall agree with the proposal.
Regarding the controversal discussed form of the issue number my favored
notation is #<number># followed by #i<number>#. I am not in favor of the plain
notation.
References in the code to issue numbers from pre-OOo (StarDivision) issue
tracker should be removed. From my point of view in the Writer code (module sw)
they are mainly used by my former personallity known as od (od@openoffice.org).
Thus, if you find in a comment something like "OD 200X-XX-XX #123456#", just
remove this part of the comment.
Best regards, Oliver.
Re: Commit message summaries
Posted by Herbert Duerr <hd...@apache.org>.
> - 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.
>
> Older commit messages can be interpreted by knowing the older
> conventions and today we have only one bugtracker.
I disagree. Undecorated issue numbers cause gratuitous confusion and
here is an example from a very recent commit:
> + // #119459# for connector shape, the start point and end point [...]
Now compare that with typical lines from the the AOO 3.4 (and OOo) code
base such as main/vcl/source/window/winproc.cxx:2369
// #119709# for some unknown reason it is possible to receive [...]
or main/sw/source/core/unocore/unodraw.cxx:2123
// --> OD 2005-02-02 #119236# - no delete of draw format for members
The source line from the recent commit refers to a bug number in our
current bugzilla instance whereas the examples from the older code refer
to bug numbers in the pre-OOo tracker.
Can someone enlighten me using the concrete examples from above why
using undecorated numbers is supposed to be better? How can one
distinguish the issue numbers if they are not decorated?
Herbert
Re: Commit message summaries
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 6/21/12 11:47 AM, Herbert Duerr wrote:
> On 21.06.2012 10:17, Jürgen Schmidt wrote:
>> We have already introduced the Patch by, Review By .. fields for adding
>> further information.
>>
>> How about logs like
>>
>> ####
>> <issuenumber>:<issue subject line>
>
> I agree that the issue subject line is better than nothing, but I prefer
> that the subject line is about why the change was made. See e.g. the six
> different changes for issue 118923. Why would anyone want the same
> change header for each commit when you can have a description instead
> that matches the change much better?
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.
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
>
> 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
Re: Commit message summaries
Posted by Herbert Duerr <hd...@apache.org>.
On 21.06.2012 10:17, Jürgen Schmidt wrote:
> We have already introduced the Patch by, Review By .. fields for adding
> further information.
>
> How about logs like
>
> ####
> <issuenumber>:<issue subject line>
I agree that the issue subject line is better than nothing, but I prefer
that the subject line is about why the change was made. See e.g. the six
different changes for issue 118923. Why would anyone want the same
change header for each commit when you can have a description instead
that matches the change much better?
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
Re: Commit message summaries
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 6/21/12 9:39 AM, Wang Zhe wrote:
> Sure, I agree with Herbert. We need some basic and rough comment for the
> code change, then others could review it much easier.
> 2012/6/21 Oliver-Rainer Wittmann <or...@googlemail.com>
>
We have already introduced the Patch by, Review By .. fields for adding
further information.
How about logs like
####
<issuenumber>: <issue subject line>
fix: <short description/summary>
(on demand only)
Patch By:
Suggest By:
Found by:
Reviewed By:
####
A common notation used by all would be of course helpful
Juergen
>> Hi,
>>
>>
>> On 21.06.2012 08:36, Herbert Duerr wrote:
>>
>>> Date: Wed Jun 20 06:58:35 2012
>>>>
>>> Was [Re: svn commit: r1351948 -
>>> /incubator/ooo/trunk/main/sd/**source/core/**CustomAnimationEffect.cxx]
>>>
>>> New Revision: 1351948
>>>>
>>>> URL: http://svn.apache.org/viewvc?**rev=1351948&view=rev<http://svn.apache.org/viewvc?rev=1351948&view=rev>
>>>> Log:
>>>> for #119951#
>>>>
>>>
>>> Recently there have been three commits with great fixes but with the
>>> problem
>>> that the log message was way too short: In my opinion just mentioning the
>>> issue
>>> number in the commit message makes following the progress of code
>>> unnecessarily
>>> difficult. I suggest to provide at least a rough idea on why something was
>>> changed in the summary, e.g.
>>> #i119951# fix the animation effect of a shape when it has been grouped
>>> would have been much better IMHO.
>>>
>>>
>> I agree here.
>>
>>
>> Not having a self-sustaining commit message reduces the quality of the
>>> repository. Adding a bit of redundancy also prevents that a typo such as
>>> transposed digits makes it almost impossible to understand why a change
>>> was done.
>>>
>>>
>> That is right. I had made a couple of these typos in the past and
>> additional existing text help in these cases a lot.
>>
>>
>> I also suggest to mention the issue tracker when referring to an issue
>>> number.
>>> In the history of the OOo project there were already three different
>>> bug-trackers were used. E.g. "issuetracker" that has been migrated to our
>>> bugzilla instance was referred to by the 'i' before the bug number such as
>>> #i123456#. Other projects in our ecosystem use similar conventions such as
>>> #fdo12345#. If we want to be good citizens in this ecosystem then we
>>> should not
>>> be egocentric by working as if there are no other trackers and there
>>> never have
>>> been other trackers.
>>>
>>> What do others think?
>>>
>>>
>> As AOO Bugzilla is our intrinsic issue database, I am in favor to mark
>> issue numbers from this issue database without any further letters, e.g.
>> #119951#.
>> In case it is needed to reference other issue databases an identification
>> of these other issue databases makes sense from my point of view.
>>
>> Best regards, Oliver.
>>
>
Re: Commit message summaries
Posted by Wang Zhe <ki...@gmail.com>.
Sure, I agree with Herbert. We need some basic and rough comment for the
code change, then others could review it much easier.
2012/6/21 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 21.06.2012 08:36, Herbert Duerr wrote:
>
>> Date: Wed Jun 20 06:58:35 2012
>>>
>> Was [Re: svn commit: r1351948 -
>> /incubator/ooo/trunk/main/sd/**source/core/**CustomAnimationEffect.cxx]
>>
>> New Revision: 1351948
>>>
>>> URL: http://svn.apache.org/viewvc?**rev=1351948&view=rev<http://svn.apache.org/viewvc?rev=1351948&view=rev>
>>> Log:
>>> for #119951#
>>>
>>
>> Recently there have been three commits with great fixes but with the
>> problem
>> that the log message was way too short: In my opinion just mentioning the
>> issue
>> number in the commit message makes following the progress of code
>> unnecessarily
>> difficult. I suggest to provide at least a rough idea on why something was
>> changed in the summary, e.g.
>> #i119951# fix the animation effect of a shape when it has been grouped
>> would have been much better IMHO.
>>
>>
> I agree here.
>
>
> Not having a self-sustaining commit message reduces the quality of the
>> repository. Adding a bit of redundancy also prevents that a typo such as
>> transposed digits makes it almost impossible to understand why a change
>> was done.
>>
>>
> That is right. I had made a couple of these typos in the past and
> additional existing text help in these cases a lot.
>
>
> I also suggest to mention the issue tracker when referring to an issue
>> number.
>> In the history of the OOo project there were already three different
>> bug-trackers were used. E.g. "issuetracker" that has been migrated to our
>> bugzilla instance was referred to by the 'i' before the bug number such as
>> #i123456#. Other projects in our ecosystem use similar conventions such as
>> #fdo12345#. If we want to be good citizens in this ecosystem then we
>> should not
>> be egocentric by working as if there are no other trackers and there
>> never have
>> been other trackers.
>>
>> What do others think?
>>
>>
> As AOO Bugzilla is our intrinsic issue database, I am in favor to mark
> issue numbers from this issue database without any further letters, e.g.
> #119951#.
> In case it is needed to reference other issue databases an identification
> of these other issue databases makes sense from my point of view.
>
> Best regards, Oliver.
>
Re: Commit message summaries
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.06.2012 08:36, Herbert Duerr wrote:
>> Date: Wed Jun 20 06:58:35 2012
> Was [Re: svn commit: r1351948 -
> /incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx]
>
>> New Revision: 1351948
>>
>> URL: http://svn.apache.org/viewvc?rev=1351948&view=rev
>> Log:
>> for #119951#
>
> Recently there have been three commits with great fixes but with the problem
> that the log message was way too short: In my opinion just mentioning the issue
> number in the commit message makes following the progress of code unnecessarily
> difficult. I suggest to provide at least a rough idea on why something was
> changed in the summary, e.g.
> #i119951# fix the animation effect of a shape when it has been grouped
> would have been much better IMHO.
>
I agree here.
> Not having a self-sustaining commit message reduces the quality of the
> repository. Adding a bit of redundancy also prevents that a typo such as
> transposed digits makes it almost impossible to understand why a change was done.
>
That is right. I had made a couple of these typos in the past and additional
existing text help in these cases a lot.
> I also suggest to mention the issue tracker when referring to an issue number.
> In the history of the OOo project there were already three different
> bug-trackers were used. E.g. "issuetracker" that has been migrated to our
> bugzilla instance was referred to by the 'i' before the bug number such as
> #i123456#. Other projects in our ecosystem use similar conventions such as
> #fdo12345#. If we want to be good citizens in this ecosystem then we should not
> be egocentric by working as if there are no other trackers and there never have
> been other trackers.
>
> What do others think?
>
As AOO Bugzilla is our intrinsic issue database, I am in favor to mark issue
numbers from this issue database without any further letters, e.g. #119951#.
In case it is needed to reference other issue databases an identification of
these other issue databases makes sense from my point of view.
Best regards, Oliver.
Re: Commit message summaries
Posted by Thorsten Behrens <th...@documentfoundation.org>.
Herbert Duerr wrote:
> I also suggest to mention the issue tracker when referring to an
> issue number. In the history of the OOo project there were already
> three different bug-trackers were used. E.g. "issuetracker" that has
> been migrated to our bugzilla instance was referred to by the 'i'
> before the bug number such as #i123456#. Other projects in our
> ecosystem use similar conventions such as #fdo12345#. If we want to
> be good citizens in this ecosystem then we should not be egocentric
> by working as if there are no other trackers and there never have
> been other trackers.
>
Hi Herbert,
yes, I think that would be helpful. There's no pre-Apache history in
svn itself, but the code is full of 'i#12345', '#123456' etc.
references - deviating from that scheme in commit messages appears
needlessly confusing.
Cheers,
-- Thorsten
Commit message summaries
Posted by Herbert Duerr <hd...@apache.org>.
> Date: Wed Jun 20 06:58:35 2012
Was [Re: svn commit: r1351948 -
/incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx]
> New Revision: 1351948
>
> URL: http://svn.apache.org/viewvc?rev=1351948&view=rev
> Log:
> for #119951#
Recently there have been three commits with great fixes but with the
problem that the log message was way too short: In my opinion just
mentioning the issue number in the commit message makes following the
progress of code unnecessarily difficult. I suggest to provide at least
a rough idea on why something was changed in the summary, e.g.
#i119951# fix the animation effect of a shape when it has been grouped
would have been much better IMHO.
Not having a self-sustaining commit message reduces the quality of the
repository. Adding a bit of redundancy also prevents that a typo such as
transposed digits makes it almost impossible to understand why a change
was done.
I also suggest to mention the issue tracker when referring to an issue
number. In the history of the OOo project there were already three
different bug-trackers were used. E.g. "issuetracker" that has been
migrated to our bugzilla instance was referred to by the 'i' before the
bug number such as #i123456#. Other projects in our ecosystem use
similar conventions such as #fdo12345#. If we want to be good citizens
in this ecosystem then we should not be egocentric by working as if
there are no other trackers and there never have been other trackers.
What do others think?
Herbert