xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Adams <gl...@skynav.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 Mon, 16 Jul 2012 13:33:09 GMT
On Mon, Jul 16, 2012 at 5:19 AM, Chris Bowditch
<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.

Mime
View raw message