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: JIRA: How to manage resolved versions (Was: [jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header)
Date Wed, 19 Dec 2012 09:25:00 GMT
Hi Glenn,

On 18/12/2012 16:27, Glenn Adams wrote:
> On Mon, Dec 17, 2012 at 7:54 AM, Chris Bowditch 
> <bowditch_chris@hotmail.com <mailto:bowditch_chris@hotmail.com>> wrote:
>     Hi Glenn,
>     On 17/12/2012 15:24, Glenn Adams wrote:
>         but after a new release, the issue would effectively apply to
>         both trunk and the new release, and an issue can only be
>         associated with one version in JIRA;
>     But why does that matter? If a bug is fixed then in v3 say, then
>     its obvious its also fixed in v4.
> Not at all. If it is fixed in the v3 branch, e.g., in order to create 
> a subsequent v3.1 release from that branch, then that doesn't imply 
> anything about a fix in a v4 branch.

This seems like a corner case to me. A bug tracking system can't tell 
you the relationship between branches, i.e.

v3 contains the fix
v3.1 was based on v2 and doesnt contain it
v4 does contain the fix because it was based on v3
v4.1 doesn't contain the fix because it was based on v3.1

I don't believe we've ever done something like the above on the FOP 
project. Although I admit having to deal with such scenarios on 
commercial projects. We also had terrible trouble with the fixed in 
version for such projects and just didn't use it, which lead to release 
planning being conducted with list of defects in e-mails or spreadsheets 
and not using the BTS.

Jira also has a concept of labels and an issue can have zero or many 
labels, so we could decide to label issues as being in particular 
releases if the PMC feels that the multiple release branch scenario is 
likely. (Labels can also be reported on so we can list defects fixed in 
a given release) The downside to labels is that they are freetext 
instead of a dropdown and anyone can create them, which leads to a long 
list of labels like v2.0, 2.0, R2.0.0, etc.

I personally don't see a problem with the proposal as FOP has always had 
a linear release pattern without multiple release branches to worry 
about but we can have a formal vote on this topic if needed.

>         if the issue isn't fixed by the time the release occurs, then
>         it is unlikely to be fixed in the release version as much as
>         being fixed in trunk; so that would argue for keeping the
>         issue associated with trunk and not the new version
>     Are you saying there is a possible flaw in the suggested process
>     that mean some bugs fixed after the release branch were created
>     are marked incorrectly. IIUC, As long as the fixed in version is
>     updated at the same point in time the release branch is created
>     this should be a non issue.
> I don't understand this.

Me neither I was trying to get you to clarify your point.




View raw message