One question. Has there been anything done to the JIRA's that originate with EAP?
I'm a little afraid that we might close those, when we shouldn't.
We don't want a repeat of what happened with EAP 5, where a bunch of EAP 4.x related
JIRA's never were fixed in AS 5.0, and we ended up having to fix a large number of
bugs again after EAP 5 shipped, which in the case of more than a few customers was a
----- Original Message -----
From: "Jason T. Greene" <jason.greene(a)redhat.com>
Sent: Tuesday, March 22, 2011 3:17:36 PM
Subject: [jboss-as7-dev] IMPORTANT New JIRA Policy & Massive JBAS JIRA Reorg/Cleanup
I'm sure many of you will agree that the JBAS jira has had a very poor
signal to noise ratio for awhile now. his has been a problem since
important issues often go unnoticed, and it's extremely time consuming
to do any kind of release or organization.
Our release model is such that we only focus on one major release at a
time. Once that happens it typically becomes part of the enterprise
product line which has it's own JIRA project (JBPAPP). Since we have a
very new architecture with 7, there isn't much value in keeping around
hundreds of stale issues which may not be relevant any more.
So, I have /closed all issues that were not assigned to an as7
as out of date.
I have also renamed all components that are no longer relevant to be
prefixed with z - Legacy (to sort at the bottom).
From now on JIRA should accurately reflect our 7 timeline and work
I am asking for everyone's help though in keeping this manageable by
doing the following:
1. When creating an issue that you intend to assign to yourself, pick
fix-for release version that you can commit to achieving. Please be
realistic in making this choice, as very few of our issues do not get
2. If you can not commit to a point in the schedule, but you just want
to log the issue to be worked on, then leave it unassigned and set the
fix-for to be "Open to Community". I am hoping this will be an easy
place to point people that want to jump in.
3. If you have an issue you know you cant work on, but think it is
timeline sensitive, then leave it unassigned and let me know about it.
We will figure out a way to resource it.
4. If you validate that a bug is valid then please schedule it or
a note so that when I go through them I can find a place for it.
5. If you are a component lead you will probably get auto-assigned.
intention is that you will either take on the issue, delegate it to
someone else, verify it and unassign, or in the worst case just
Also note that I may close issues that are continually not resolved
scheduled, so if you really care about the issue please schedule it
If we do this right, we should start to see that each release has a
manageable number of issues on it, and that everyone has a reasonable
number assigned to them.
If you have any questions or any other ideas on how we can get a more
accurate reflection of our work in JIRA, then let me know.
Jason T. Greene
JBoss, a division of Red Hat
jboss-as7-dev mailing list