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 Thu, 19 Jul 2012 08:14:54 GMT
On 18/07/2012 14:06, mehdi houshmand wrote:

Hi Mehdi,

> As we've seen this morning, my ineptitude at even basic bureaucracy 
> doesn't really qualify me to show a bias to either side, but I'll give 
> my 2 cents worth since I am a stakeholder in this debate:
>
> On 18 July 2012 13:17, Vincent Hennebert <vhennebert@gmail.com 
> <mailto:vhennebert@gmail.com>> wrote:
>
>     <snip/>
>     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.
>
>
> Surely having lots of comments is a good thing? It means there's been 
> a discussion about the issue and possibly some conclusion has been 
> come to as to how to solve the problem. Even if the comments don't 
> arrive at a conclusion, then surely having the discussion would better 
> document nuances surrounding any particular issue?

+1. I totally agree and that's one of the key benefits of using BTS over 
status.xml.

>
> The only time this can become confusing is if there are disparities in 
> the flow of the conversation between bugzilla comments and mailing 
> list posts. This doesn't happen very often so I don't really see this 
> as a consideration we should be trying to mitigate.

Yes I agree that is the exception rather than the rule.

>     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.
>
>
> Agreed! I think whatever we decide, we must be consistent if only to 
> prevent confusion. It's easier following one rule for all than it is 
> remember and adhering to caveats.
>
>     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.
>
>
> Again I agree with Vincent here, that status.xml gets me every time! I 
> almost invariably forget to update it, now again, that's my bad but it 
> does seem somewhat redundant if all that information is in 
> bugzilla/JIRA. I appreciate it's used for release info, but there's 
> got to be a better solution.
>
> I'm happy to follow the consensus on this one and I'm glad we've come 
> to an agreement.

Yes I think we have consenus. I can start a formal vote if necessary, 
but I don't think it is in this instance.

Thanks,

Chris

>
> Mehdi



Mime
View raw message