From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: jboss-as7-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On Wednesday 23 March 2011 02:47 AM, Jason T. Greene wrote: > > So, I have /closed all issues that were not assigned to an as7 release/ > as out of date. There are few issues which are being tracked for a (probable) JBoss AS 6.1.0 release. But I don't see that version available in the drop down for "Fix for version" while creating a new JIRA. It also isn't listed in the versions section of the project https://issues.jboss.org/browse/JBAS#selectedTab=com.atlassian.jira.plugi... How do we track those? -Jaikiran

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&quot;&lt;jason.greene(a)redhat.com&gt; > To: jboss-as7-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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?clicke... > > 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&quot;&lt;jason.greene(a)redhat.com&gt; >>> To: jboss-as7-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Assuming it wasn't intentional to archive it, could a project admin please unarchive that version? -Jaikiran On Wednesday 23 March 2011 05:04 PM, Dimitris Andreadis wrote: > The version needs to be "unarchived" in order to see it again. > > On 23/03/2011 12:14, Jaikiran Pai wrote: >> On Wednesday 23 March 2011 02:47 AM, Jason T. Greene wrote: >>> >>> So, I have /closed all issues that were not assigned to an as7 release/ >>> as out of date. >> There are few issues which are being tracked for a (probable) JBoss AS >> 6.1.0 release. But I don't see that version available in the drop down >> for "Fix for version" while creating a new JIRA. It also isn't listed in >> the versions section of the project >> https://issues.jboss.org/browse/JBAS#selectedTab=com.atlassian.jira.plugi... >> >> How do we track those? >> >> -Jaikiran > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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!