Henri Yandell wrote:
On 6/2/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
Having done two releases I have some thoughts on how we are using
JIRA. I imagine that there are a
number of thoughts on how we can manage JIRA.
I tend to do release management tasks too, so thought I'd offer thoughts.
Currently we create a release and then pretty much dump most
everything into it. What ends up
happening is that we end up with more JIRAs than we have time to
complete and end up with over a
hundred JIRAs than move from version to version. I don't think this
solution works because one
never knows what's really left in a release to complete before its
golden. Our intentions are noble
(let's fix all those bad bugs) but of course our time is a limited
resource and we can't always get
everything done.
At first I thought this was bad, but the existence of a 1.x version
means that you can still keep the vision of the major release going
without making it hard to do minor releases. Seems like a good idea to
me.
I propose (this is not a vote; simply a discussion thread) that new
JIRA's are assigned to a release
if the person assigning it is going to fix it and they assign it to
themselves.
Probably a bit too far. The process here is going to depend on when
you branch the release, so:
*) pre-branch - general conversation about the important things in
this release (and are thus assigned to 1.2 etc), people fixing things
randomly and throwing in (and as they resolve they move to 1.2 - there
should be no resolveds in 1.x).
*) post-branch - nothing should move to 1.2 without lots of discussion.
For new issues that are not being worked on they get put into another
category like 1.x, wishlist,
etc.
New issues are unversioned. Component leads look at the issue and then
assign them to 1.x, wishlist, 2.x, verification required, wontfix
(resolving) et al.
I am concerned that having Component leads is against the ASF way. The
last thing we want is for the community to feel there is a hierarchy and
opening up the opportunity for people to claim they are the leader of
component/team X. Everyone should be a peer.
Maybe have a weekly report of unassigned issues so the release manager
can nudge people.
I always have an urge to have IRC triage sessions with decisions
reported back to the mail list, interesting to hear what Ken thinks on
that.
The IRC triage sessions are a good idea - with the importance on results
being posted on the dev list. Hopefully Jason will be able to get the
IRC logs posted to the dev list, so no-one misses out on the detail.
I'm not sure how to handle assignment of JIRAs as they generally fall
into someone's area of
expertise but I think the fact their assigned to someone might scare
someone away from looking at it
. Thoughts?
If a JIRA is not marked as in-progress then people should be encouraged
to ask the assignee whether they can take it off their hands.
I am also wondering whether we should have Geronimo Bug Guidelines page
(e.g. like http://db.apache.org/derby/DerbyBugGuidelines.html ) on the
website off the JIRA link that discusses JIRA usage and may help prevent
JIRA being used as a place to ask questions, with the link to JIRA on
that page.
I would define leads for each component and delegate to them as
release manager to give me a status of where things are - however I
would make the default assignee be unassigned to encourage community.
I think we need more discussion on the pros and cons of having component
leads.
Hen
