qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpid Improvement Process
Date Fri, 14 Jan 2011 17:31:25 GMT
On 01/13/2011 03:49 PM, Robbie Gemmell wrote:
> I would like to see the existing toolset used properly before we think
> about bringing another process into use, specifically JIRA. Having
> recently undertaken the Release Manager role I now more fully
> appreciate the pain those who have undertaken the process in the past
> have gone through in this area.

We certainly do need to better manage JIRA, I agree with you completely 
there. However I think the QIP idea can actually assist in that and 
complement it.

Every agreed QIP would result in at least one JIRA. Having a template 
that provides some standard structure in which the proposal addresses 
some key questions and having some discussion around the proposal on 
list[1] would in my view improve the quality of those JIRAs as well.

[1] JIRA email traffic generates a lot of noise and I have it all 
redirected to a folder (I doubt I am alone in this).

> JIRA is there to allow tracking issues and the related changes to the
> code base, however at present JIRAs often aren't created at all, or
> are simply created and then never updated/referenced. Just taking a
> quick look back through recent commits, the vast majority don't
> specify a JIRA in the commit log. If these actually have an associated
> JIRA and it isn't sitting in the resolved state then how is anyone
> looking at it meant to know whether it has actually been worked on? If
> it was worked on then how is anyone interested (user or developer)
> meant to know what changes were actually made in order to
> fix/implement it? If there was a deep and meanigful discussion about a
> change on a JIRA, how is someone meant to find it and vice versa?
> Alternatively, if no JIRA at all was created how are people meant to
> find out a problem was even fixed / feature added etc without
> searching through the commits and knowing what to look for?
> Not updating a JIRA to say its in progress / resolved / reopened etc
> is one thing, but making it unnecessarily difficult / impossible for
> anyone else to do so is another. Thanks to some additional prodding
> from Justin I did actually get some help with the process eventually
> for 0.8, but with those JIRAs I had to tidy up myself it took a lot
> more work than it should have. I'm also sure there will be JIRAs that
> have been pushed out to the next version during the release cycles but
> have actually been actioned already, except it wasn't possible for
> anyone to tell 6 months later.
> I realise there are changes where it sometimes doesn't seem necessary
> to make a JIRA (e.g. add a comment, correct a typo, update a readme,
> etc) and I will admit to doing a commit without one on occasion, but
> that is the vast minority of the time and should not be the norm for
> anyone. Ideally we should just have a JIRA for everything, but we are
> so bad at this as a community I would actually say we should have a
> commit hook put in place to enforce presence of a JIRA tag in commit
> logs to encourage the behaviour.

I would rather start complaining about specific commits which should 
have had a Jira referenced and do not - the 'name and shame' approach!

Automated enforcement of this sort can sometimes enforce the letter of 
the law without really doing much for its spirit.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message