[jboss-as7-dev] IMPORTANT New JIRA Policy & Massive JBAS JIRA Reorg/Cleanup

[Bruno Georges]

Note that there is a goal to move JBPAPPs to Bugzilla for EAP6.
On 23 Mar 2011, at 22:23, Jason T. Greene wrote:

> JIRA is pretty limited in these kinds of searches. We would need a 
> custom crawler whether they are open or not. I closed all of the 
> untracked issues with a resolution of "Out of Date", so that it would be 
> easy to find them if need be.
> 
> If we can find someone to work on it, we could create a report that 
> finds all linked issues that are not marked Closed/Done from JBPAPP. 
> Another report could look for close matches of the same issue subject.
> 
> On 3/23/11 6:57 AM, Dimitris Andreadis wrote:
>> This is done now so I'm not sure if it's possible to automatically spot those JBPAPP jiras
>> pointing back to JBAS ones with a filter or something:
>> http://confluence.atlassian.com/display/JIRA042/Advanced+Searching?clicked=jirahelp
>> 
>> It seems probably easier to check open JBPAPP jiras individually to see if they point to
>> JBAS reports that are still relevant and should be handled in AS7, even though the code base
>> is so much different.
>> 
>> On 23/03/2011 04:41, Andrig Miller wrote:
>>> 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 complete embarrassment.
>>> 
>>> Andy
>>> 
>>> ----- Original Message -----
>>>> From: "Jason T. Greene"<jason.greene at redhat.com>
>>>> To: jboss-as7-dev at lists.jboss.org
>>>> Sent: Tuesday, March 22, 2011 3:17:36 PM
>>>> Subject: [jboss-as7-dev] IMPORTANT New JIRA Policy&   Massive JBAS JIRA Reorg/Cleanup
>>>> Hi Everyone,
>>>> 
>>>> 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
>>>> release/
>>>> 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
>>>> queue.
>>>> 
>>>> 
>>>> 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
>>>> a
>>>> 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
>>>> rescheduled.
>>>> 
>>>> 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
>>>> leave
>>>> 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.
>>>> The
>>>> 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
>>>> unassign.
>>>> 
>>>> Also note that I may close issues that are continually not resolved
>>>> when
>>>> scheduled, so if you really care about the issue please schedule it
>>>> reliably.
>>>> 
>>>> 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.
>>>> 
>>>> Thanks!
>>>> 
>>>> --
>>>> Jason T. Greene
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
> 
> 
> -- 
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev