xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vhenneb...@gmail.com>
Subject Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
Date Wed, 18 Jul 2012 12:17:52 GMT
Hi Alexios,

thanks for you input.

On 18/07/12 01:05, Alexios Giotis wrote:
> Hi Vincent,
> 
> On Jul 17, 2012, at 12:10 PM, Vincent Hennebert wrote:
> 
>> On 13/07/12 22:52, Alexios Giotis wrote:
>>> A change log or "release notes" can be generated by Jira [1]. For example, [2]
is the release notes for Apache PDFBox 1.7. Bug or issue titles (at least) tend to be better,
if it is known that the change log is generated by such a system. Glenn wrote very good points.
It will help the FOP community if everybody is recording in BZ or Jira substantial changes,
whether this is an existing practice or not. 
>>
>> An automatically generated change log is definitely desirable. But we
>> already have that with status.xml. What else does Bugzilla/JIRA bring?
> 
> It improves documentation. For example, I frequently execute "svn annotate", read the
usually brief commit message and then refer to the bug for more info (and context in my case).
I don't like the fact that I have to rely to another system, but it helps, especially for
old change sets.

Well, the problem is probably not the lack of a BTS here, it’s probably
the commit message that shouldn’t be that short. And a longer
description should be in status.xml anyway. Also, I find the list of
comments that usually appears in Bugzilla entries confusing more than
anything else. You have to wander through the comments to understand
what is going on.

That said, if a bug affects the rendering part of FOP which is not
really unit-testable at the moment, the commit is unlikely to contain
any test, so it helps to be able to retrieve an example output on
Bugzilla. And I suppose that for the sake of consistency, the same
should be done for layout bugs.

Also, I’m just remembering that we will at some point switch to the
Apache CMS to generate the website and that the status.xml logic may not
be ported there. That’s probably the biggest factor that would push me
to switch to Bugzilla actually.


<snip/>

>> If the end result is to have to very same change log as what is
>> generated from status.xml right now, then I’m not sure I see the point.
> 
> The end result is to provide a documentation trail. I initially replied to this thread
because Jira is not (yet) used in FOP and it happens to provide this feature.
> 
>>
>> If the community decides to move to a BTS to log changes, I won’t oppose
>> it but I will do it reluctantly. Also, I would be even more bothered to
>> have to both 1) add an entry to status.xml 2) add a BZ entry. So I would
>> suggest that we deprecate status.xml as soon as we make the move, and
>> find a way to integrate the new change list to the website.
> 
> You are right about deprecating status.xml. I hope that in the long term you will see
the benefits of this practice and willingly file bugs (BZ) or create issues (Jira).

Since everyone seems to be in favour of switching to Bugzilla, I suppose
I’ll start from now on. But I urge the proponents of this move to
convert the status.xml logic as soon as possible.


Vincent

Mime
View raw message