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 Fri, 13 Jul 2012 15:08:32 GMT
On 13/07/12 14:07, Glenn Adams wrote:
> On Fri, Jul 13, 2012 at 2:05 AM, Pascal Sancho <psancho.asf@gmail.com>wrote:
>> IMHO, using a bugtracker system to list bugfix or changes is a good idea.
>> But today, the practice in FOP project is to fill this list directly
>> in the cited page.
>> We can adopt a new policy here and have a change/bugfix list using
>> bugtracker facilities.
>> That could be done when we'll migrate to Jira.
>> IIUC, Bugzilla entries will be migrated to Jira in the future.
>> Waiting this migration, we can today begin to systematically fill a
>> new Bugzilla entry, to keep trace in Jira.
> Thanks, yes, I agree with this, but I don't think I'm suggesting a new
> policy. We have a policy today of telling the community to report bugs in
> BZ, then we make fixes and close (or reject) those bug reports, where fixes
> change the code base and the bug is closed and a entry made in status.xml.

We’ve never had such a policy. In fact, it happened several times in the
past that a bug fix was committed straight away after it had been raised
on fop-users.

We ask users to file a Bugzilla entry only when we can’t look at the
issue immediately, in order to keep track of it.

status.xml has always been better kept up-to-date than Bugzilla. Since
it contains information that is not in Bugzilla, it is more important.

We can decide to change that and use a bug tracking system instead, but
in the same time we do that we will have to have in place a new
mechanism to generate the changes [1] page. Also, we will most likely
have to find a way to feed the BTS with the content of status.xml that
is not there yet.

[1] http://xmlgraphics.apache.org/fop/changes.html

> When we committers make changes that are essentially bug fixes (as opposed
> to minor cleanup), then we should not bypass this existing, accepted
> practice, because doing so creates unnecessary exceptions in our
> documentation and process trail. In other words, let's be consistent, and
> document bugs we fix independently in the same fashion as when those bugs
> are first reported by the community.
> I think this is a reasonable process and should not be contravened for the
> sake of expediency.
> G.


View raw message