Re: [udig-devel] Issue tracker proceedure and protocol ideas for distrib

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Hi Eric - since you started your idea as a reply to a thread on getting 
organized for this weekends code sprint we are getting people a little 
confused. The question I was answering was about the existing workings 
of Jira. Silvia was asking how to help; and if a priority had been set 
fo issues needing testing.

I do not feel I effectively answered her question; there are a lot of 
issues that need testing; and we will not be able to take stock of the 
answer until we have completed reviewing all the issues.

Eric Jarvies wrote:
> Yes, these all make sense to me, but are not what I am referring to.
Understood; I was answering Silvia's question - we can return to your 
email thread about organizing our issue workflow if you like (but right 
now the two email threads are getting confused; and making organization 
for this weekend difficult).
> > I also note that this page is really good and describes a few new 
> > issue states that may be of interest to Eric:
> > - http://jira.codehaus.org/secure/ShowConstantsHelp.jspa
> I understand the JIRA and it's intended functionality.  What i have 
> been referring to is the human element/side of things.  I have 
> suggested that we create a human rule system that specifically handles 
> tickets... both bugs and feature requests.  Whilst also suggesting we 
> get rid of the complex clutter.
Understood my general feedback still stands:
- we can document our rule system in Jira (so the tool will help us once 
we know what we want). I have two examples where projects have added a 
workflow with additional steps similar to what you described.
- testing on multiple platforms may be beyond our abilities except on a 
case by case basis - the open source "relesae early release often" may 
have to act as a substitute for lack of dedicated testers.
- the difference between fixing a bug and fixing a bug and making a 
build is around 1/2 day (and a lot of waiting for files to upload) while 
all developers (and indeed anyone) can make a release following the 
procedure in our wiki I am not sure this is an effective way to roll out 
a single change. I would rather make a uDig release every month (or 
every two weeks) than expect this of our developer community

What I am missing here is not your individual suggestions; but what you 
are wanting to accomplish with them (right now the amount of work you 
document would preclude me from working on uDig). So I feel I am missing 
something ...

Jody