xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bowditch <bowditch_ch...@hotmail.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 Tue, 17 Jul 2012 07:37:07 GMT
On 16/07/2012 14:33, Glenn Adams wrote:

Hi Glenn,

> On Mon, Jul 16, 2012 at 5:19 AM, Chris Bowditch 
> <bowditch_chris@hotmail.com <mailto:bowditch_chris@hotmail.com>> wrote:
>     I'm in favour of changing the policy to always open a
>     Bugzilla/Jira entry for every bug fixed in FOP. However, it won't
>     always be possible to upload resources to replicate the issue.
>     Whilst we can clean any FO Files of senstive data we can't
>     necessarily do the same for Images, Fonts or other confidential
>     resources. As long as you can accept that sometimes bugs will be
>     missing resources required to replicate the issue then I'm +1 for
>     this policy change.
> BTW, I agree with this point, and I was not asking for a BZ entry that 
> included all needed to replicate it. That has never been a requirement 
> or goal, although, when it is possible to do so without an 
> extraordinary effort, it is reasonable to do as a 2nd order task. I'm 
> just looking for BZ entries (or equivalent) for substantive 
> (non-trivial) code changes to help with tracking. I'll leave it up to 
> the committer to decide what is substantive vs trivial. Examples of 
> changes I would find trivial: fixing warnings (e.g., checkstyle, etc), 
> adding/fixing javadoc or code comments, simple  (non-extensive) code 
> refactoring, cleanup, or organization. Common sense should apply.

Thanks Glenn - I just wanted to make sure you were aware of that before 
we commit to changing the policy. I do agree with the points you've 
raised. I make the development teams here have a bug in place before 
making any code changes to FOP or otherwise so fully appreciate the 
benefits that brings around tracking. I'm not sure why that wasn't 
adopted on Apache FOP in the past, but I'm in favour of implementing it, 
so here's my +1



View raw message