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 12:46:39 GMT
Andy Seaborne wrote:
> On 10/11/11 22:52, Leo Simons wrote:
>>> 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.
> +1
>> 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.
> +1
> Actions speak louder than words.
>> 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
> +1
> I see no point setting expectations (e.g. saying when things will be 
> done) without a mechanism to reflect costs and trade-offs.All that 
> happens is that there will be a growing pile of guilt.  At which point 
> either release get pushed out or expectations are not met.  Both are bad.


Thank you Leo and Andy, you convinced me.

I've just removed all the forward looking "Fix Version/s" for the currently
open bugs. If I left any there for an open bug is a mistake and I'll fix it
when I find it.

I left "Fix Version/s" for the closed bugs.
Do you see value on those or you want me to remove them as well?
I still see there is some value on having a "Fix Version/s" field on
closed bugs, but if there isn't agreement on that I am going to remove
those as well.

Related to this... keeping a ChangeLog.txt file, such as ARQ for example:
is very useful (but it's also easy to forget to update it when an issue
is closed... it happened a couple of times or probably more to me...
I closed an issue and I forgot to update the ChangeLog.txt file).


>     Andy

View raw message