incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: JIRA issues and "Fix Version/s"...
Date Fri, 11 Nov 2011 00:12:37 GMT
Hi Leo

Leo Simons wrote:
> On Thu, Nov 10, 2011 at 4:31 PM, Paolo Castagna
> <> wrote:
>> Paolo Castagna wrote:
>>> Hi,
>>> perhaps we can try to use JIRA "Fix Version/s" to assign JIRA
>>> issues to releases (they can be moved as we wish).
>> We also should probably clarify how we want to use the "Fix Version/s"
>> in JIRA. There is also a "Fix for Version" field, but I do not see it
>> available in the JIRA version which Apache is using or maybe there is
>> a reason why it's disabled.
>> Mentors?
> Hmm, what? I don't know what you mean. Jira by default has two version
> fields, "Affects Version" and "Fix Version", and ASF jira is no
> different. It's possible to add custom fields to jira but it's better
> not to.
> Generally people use "Fix Version" as "target fix version" until the
> issue is closed, at which point the "fix version" is updated to the
> version that the issue is / will be actually fixed in.
>> If a different field isn't available we could decide that:
>>  - Fix Version/s for an open bug with a value of an unreleased version
>>   is an expression of intent to fix that issue by the time we do a
>>   release
>>  - Fix Version/s for a closed bug with a value of a released version
>>   is to say that that issue has been resolved (and released in that
>>   specific release).
>> Other Apache projects seems to adopt this practice, for example:
>> What do you think?
> Lots of things.
> For open source projects I prefer to not set fix versions at all until
> an issue is actually fixed. When you do set it, match the version
> number to the actual number in the associated artifact(s) that users
> download, and nothing else. That way, the jira release notes are
> accurate.
> Similarly, I don't think due date is useful in our context.
> Jira is great for project planning and scheduling and tracking
> commercial software delivery. But for community open source projects,
> it is better not to measure or promise or schedule as precisely as you
> do in the commercial environment. The dynamic is different.
> My advice would be not to focus too much on capturing intentions and
> roadmaps and long-term plans in jira or in documentation. Discuss
> plans on the mailing list, make sure you have consensus on the general
> direction and goals, and then everybody works towards those goals as
> they have time and energy available. Don't publish long term schedules
> out to your user community, only announce things when they are
> actually implemented.
> If you do want to do some kind of scheduling/metrics using jira,
> there's a bunch of stuff you can look at beyond the roadmap. I'd
> suggest an important one would be average age and resolution time of
> bugs (and only bugs), and another one is average age and resolution
> time for issues that have a patch submission, but that one is a bit
> harder to do a report on.
> In other words, do things pretty much like jena has always done
> them...but hey, you asked ;-)

Ok, I'll take the advice and remove the "Fix Version/s" when used in
forward looking/planning mode. But, I'll leave them in when an issue
is closed pointing to the version when the issue has been fixed.

I still thing there is some value in communicating (closer to a release
what's still missing so that people who want to help out knows where
they can help).

Long email threads do not work so well as a list of issues on JIRA
grouped by a future release version. I am not saying we do this for
medium-long term stuff (I'll remove what I did on JIRA), but I do not
see what are the cons in the short term.

Thanks Leo.


> cheerio,
> Leo

View raw message