Re: Using JIRA
Ahh, that's right. I wonder if it would be handy to add that state to all issues so that new people can submit patches and we would have a way to know when a patch is ready to be picked up by a committer and applied. Regards, Alan On Jan 27, 2007, at 6:13 AM, Vamsavardhana Reddy wrote: I observed that a JIRA will show up in "Patch Availble" only if it is marked as improvement and Begin RTC review is clicked. Vamsi On 1/25/07, Donald Woods <[EMAIL PROTECTED]> wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2 - 1 1.2 - 1 1.x - 2 M2 - 4 Beta1 - 2 2.0 - 12 Wish- 6 Verif - 1 Unsch - 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. -Donald Hernan Cunico wrote: > Howdy, > it may sound weird asking this now but I'm either creating JIRAs the > wrong way or we are not displaying the all the info in > http://issues.apache.org/jira/browse/geronimo (or I just don't know how > to read it) > > On the JIRA front page for GERONIMO you can see open issues due to be > fixed per version. > When I create a JIRA for a specific version I normally specify the > "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box > and leave the *Fix Version/s:* empty as I don't really know for sure > when that issue is going to be fixed unless I am the assignee. > > This issue I just created does not get listed (counted actually) for > that particular version in the project's JIRA home page. > > Is this query is automatically provided by JIRA or we can customize it > to show the affected version instead? > At this particular point in time the actual setting show 5 open issues, > if we could change it to affected versions it would show 16. > > Does this make any sense at all? > > Again, it might be just me not really understanding how to use JIRAs. > > Comments appreciated > > Cheers! > Hernan > > >
Re: Using JIRA
I observed that a JIRA will show up in "Patch Availble" only if it is marked as improvement and Begin RTC review is clicked. Vamsi On 1/25/07, Donald Woods <[EMAIL PROTECTED]> wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2 - 1 1.2 - 1 1.x - 2 M2 - 4 Beta1 - 2 2.0 - 12 Wish- 6 Verif - 1 Unsch - 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. -Donald Hernan Cunico wrote: > Howdy, > it may sound weird asking this now but I'm either creating JIRAs the > wrong way or we are not displaying the all the info in > http://issues.apache.org/jira/browse/geronimo (or I just don't know how > to read it) > > On the JIRA front page for GERONIMO you can see open issues due to be > fixed per version. > When I create a JIRA for a specific version I normally specify the > "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box > and leave the *Fix Version/s:* empty as I don't really know for sure > when that issue is going to be fixed unless I am the assignee. > > This issue I just created does not get listed (counted actually) for > that particular version in the project's JIRA home page. > > Is this query is automatically provided by JIRA or we can customize it > to show the affected version instead? > At this particular point in time the actual setting show 5 open issues, > if we could change it to affected versions it would show 16. > > Does this make any sense at all? > > Again, it might be just me not really understanding how to use JIRAs. > > Comments appreciated > > Cheers! > Hernan > > >
Re: Using JIRA
Jira is working correctly. We, the Geronimo team, added a status called "Patch Available". The whole point of the status Patch Available is to indicate that a patch is ready to be picked up and applied by a committer. Once it's picked up by a committer, there's no point in tracking it as a patch in the Status section. Regards, Alan On Jan 24, 2007, at 12:18 PM, Donald Woods wrote: Is there a way to update the Status field to Patch Available, or is JIRA suppose to do that for us automatically? Have we extended/ configured JIRA in such a way that we broke it? -Donald Alan D. Cabrera wrote: On Jan 24, 2007, at 11:27 AM, Donald Woods wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2- 1 1.2- 1 1.x- 2 M2- 4 Beta1- 2 2.0- 12 Wish- 6 Verif- 1 Unsch- 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. Yes, that section shows the issues by status. There are four issues waiting to be picked up. Regards, Alan
Re: Using JIRA
Is there a way to update the Status field to Patch Available, or is JIRA suppose to do that for us automatically? Have we extended/configured JIRA in such a way that we broke it? -Donald Alan D. Cabrera wrote: On Jan 24, 2007, at 11:27 AM, Donald Woods wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2- 1 1.2- 1 1.x- 2 M2- 4 Beta1- 2 2.0- 12 Wish- 6 Verif- 1 Unsch- 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. Yes, that section shows the issues by status. There are four issues waiting to be picked up. Regards, Alan smime.p7s Description: S/MIME Cryptographic Signature
Re: Using JIRA
On Jan 24, 2007, at 11:27 AM, Donald Woods wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2 - 1 1.2 - 1 1.x - 2 M2 - 4 Beta1 - 2 2.0 - 12 Wish- 6 Verif - 1 Unsch - 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. Yes, that section shows the issues by status. There are four issues waiting to be picked up. Regards, Alan
Re: Using JIRA
Yeah I noticed this as well. On Jan 24, 2007, at 2:27 PM, Donald Woods wrote: Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2 - 1 1.2 - 1 1.x - 2 M2 - 4 Beta1 - 2 2.0 - 12 Wish- 6 Verif - 1 Unsch - 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. -Donald Hernan Cunico wrote: Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http:// issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated Cheers! Hernan -sachin
Re: Using JIRA
Has anyone noticed that the JIRA Project Summary - Patch Available count is not correct? https://issues.apache.org/jira/browse/GERONIMO Currently, it only shows 4 issues with patches, but there are - 1.1.2 - 1 1.2 - 1 1.x - 2 M2 - 4 Beta1 - 2 2.0 - 12 Wish- 6 Verif - 1 Unsch - 28 So, why isn't the count showing 57 instead? It seems to only be counting the ones that have Status=Patch Available and ignoring those with Patch Info=Patch Available. -Donald Hernan Cunico wrote: Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http://issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated Cheers! Hernan smime.p7s Description: S/MIME Cryptographic Signature
Re: Using JIRA
On Jan 24, 2007, at 6:48 AM, Vamsavardhana Reddy wrote: I think that Jira is working correctly as is. It should not show up on the radar, http://issues.apache.org/jira/browse/geronimo, until someone makes a commitment to fixing it for a particular release at which time the issue gets assigned "Fix Version/s". If you look at I was under the impression that the "Fix Version/s" represents the versions in which the reporter would like to see the fix, but not as a commitment from someone to fix it in a release. May be a wiki page with details on how to use the JIRA will help. Or is there one already?? Well, we could manage the issues that way. But, imo, the dashboard is much more useful as tactical display as to what is going to be done for what version. This informs users what is coming down the pipeline. If we switch to versions that the reporter would like to see the fix several things will happen. It is likely that the reporter will mark the next version as the version to fix. It is also possible that it would not get fixed for that version. When this occurs, we would have to ask all the reports to update their wish list. Also, the dashboard would then become a display of wish lists with no clear visibility as to what will get released when. The best way that a reporter can indicate his/her opinion on when it should get fixed is via priority. I think that there is a wiki page somewhere... Regards, Alan
Re: Using JIRA
On 1/20/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote: > Howdy, > it may sound weird asking this now but I'm either creating JIRAs > the wrong way or we are not displaying the all the info in http:// > issues.apache.org/jira/browse/geronimo (or I just don't know how to > read it) > > On the JIRA front page for GERONIMO you can see open issues due to > be fixed per version. > When I create a JIRA for a specific version I normally specify the > "affected version" (let's say 2.0-M2) in the *Affects Version/s:* > box and leave the *Fix Version/s:* empty as I don't really know for > sure when that issue is going to be fixed unless I am the assignee. > > This issue I just created does not get listed (counted actually) > for that particular version in the project's JIRA home page. > > Is this query is automatically provided by JIRA or we can customize > it to show the affected version instead? > At this particular point in time the actual setting show 5 open > issues, if we could change it to affected versions it would show 16. > > Does this make any sense at all? > > Again, it might be just me not really understanding how to use JIRAs. > > Comments appreciated I think that Jira is working correctly as is. It should not show up on the radar, http://issues.apache.org/jira/browse/geronimo, until someone makes a commitment to fixing it for a particular release at which time the issue gets assigned "Fix Version/s". If you look at I was under the impression that the "Fix Version/s" represents the versions in which the reporter would like to see the fix, but not as a commitment from someone to fix it in a release. May be a wiki page with details on how to use the JIRA will help. Or is there one already?? the description below the Versions column on the home page you will see "with open issues due to be fixed per version". This indicates that someone has made a commitment to complete the issue for that version. You can make your own personal report and add it to your personalized portal page. Regards, Alan
Re: Using JIRA
On Jan 19, 2007, at 2:47 PM, Hernan Cunico wrote: Alan D. Cabrera wrote: On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote: Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http:// issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/ s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated I think that Jira is working correctly as is. It should not show up on the radar, http://issues.apache.org/jira/browse/geronimo, until someone makes a commitment to fixing it for a particular release at which time the issue gets assigned "Fix Version/s". So then that page is not representative of the number of issues open against a particular version. It looks more like a wish list of issues to be resolved by that particular release. If done correctly it should look like a list of issues that people have made a commitment to fix. This dashboard is really for outsiders to get a tactical sense of what's coming down the pipeline in terms of releases, not the defect rate of previous versions. If you look at the description below the Versions column on the home page you will see "with open issues due to be fixed per version". This indicates that someone has made a commitment to complete the issue for that version. "with open issues due to be fixed per version" for me has a different meaning. IMO all issues need to be fixed, assigned or not, my point is that there are a bunch more issues that have been reported that are not being listed. Sometimes, actually quite often, bugs have a long life and can span many release versions. If these bugs showed up in the dashboard we would end up with inflated figures as to the workload that is waiting to be done. A more accurate list of work that needs to be resolved is on the right hand side, Open Issues By Priority. Maybe there should be a condition that one cannot specify the "Fix versions" unless that issues is assigned to that person, then we know for sure who made the commitment to get that issue fixed for that particular release. This has always been my desire since just dumping issues into a potential release w/ no real person making a commitment to fix dilutes the usefulness of the tactical dashboard. Regards, Alan
Re: Using JIRA
Alan D. Cabrera wrote: On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote: Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http://issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated I think that Jira is working correctly as is. It should not show up on the radar, http://issues.apache.org/jira/browse/geronimo, until someone makes a commitment to fixing it for a particular release at which time the issue gets assigned "Fix Version/s". So then that page is not representative of the number of issues open against a particular version. It looks more like a wish list of issues to be resolved by that particular release. If you look at the description below the Versions column on the home page you will see "with open issues due to be fixed per version". This indicates that someone has made a commitment to complete the issue for that version. "with open issues due to be fixed per version" for me has a different meaning. IMO all issues need to be fixed, assigned or not, my point is that there are a bunch more issues that have been reported that are not being listed. Maybe there should be a condition that one cannot specify the "Fix versions" unless that issues is assigned to that person, then we know for sure who made the commitment to get that issue fixed for that particular release. You can make your own personal report and add it to your personalized portal page. Yup, something like that I'm using for the release notes and pulling some dynamic content directly from JIRA. Cheers! Hernan Regards, Alan
Re: Using JIRA
On Jan 18, 2007, at 6:12 AM, Hernan Cunico wrote: Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http:// issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated I think that Jira is working correctly as is. It should not show up on the radar, http://issues.apache.org/jira/browse/geronimo, until someone makes a commitment to fixing it for a particular release at which time the issue gets assigned "Fix Version/s". If you look at the description below the Versions column on the home page you will see "with open issues due to be fixed per version". This indicates that someone has made a commitment to complete the issue for that version. You can make your own personal report and add it to your personalized portal page. Regards, Alan
Using JIRA
Howdy, it may sound weird asking this now but I'm either creating JIRAs the wrong way or we are not displaying the all the info in http://issues.apache.org/jira/browse/geronimo (or I just don't know how to read it) On the JIRA front page for GERONIMO you can see open issues due to be fixed per version. When I create a JIRA for a specific version I normally specify the "affected version" (let's say 2.0-M2) in the *Affects Version/s:* box and leave the *Fix Version/s:* empty as I don't really know for sure when that issue is going to be fixed unless I am the assignee. This issue I just created does not get listed (counted actually) for that particular version in the project's JIRA home page. Is this query is automatically provided by JIRA or we can customize it to show the affected version instead? At this particular point in time the actual setting show 5 open issues, if we could change it to affected versions it would show 16. Does this make any sense at all? Again, it might be just me not really understanding how to use JIRAs. Comments appreciated Cheers! Hernan
Re: Thoughts on using JIRA more effectively
Point well taken as that certainly could bubble up as a problem if one person was elevated above other in the group. John Sisson wrote: Matt Hogstrom wrote: John Sisson wrote: 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. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. I agree that people have natural areas of expertise. I am just wary of seeing people marketed as the "Leader of component/team X" by their employers or in articles/books (and they have the JIRA screen to back it up without an explanation of what it really means). What if two people consider themselves experts in a component, AFAIK, JIRA can only have one lead for a component? Will one get upset at the other being chosen as the Lead? How is a lead selected and what is the length of their term. In a perfect world I wouldn't see any problems with this, but I can see some potential issues here. What do others think? John 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. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) I would be happy to put together a page similar to Derby's for review, I'll created GERONIMO-2080 and assigned to myself. John I woul
Re: Thoughts on using JIRA more effectively
- a list of bugs that *someone* ought to look at for a release - features (and more rarely, bugs) that should be looked at, but not in the current release - features that people have asked for but are not possible in the near term If we got the JIRA label plugin ( http://confluence.atlassian.com/ display/JIRAEXT/JIRA+Label+Plugin ) installed we could add labels (aka tags) to issues to add this type of metadata to issues. - a screen showing issues with attached patches, perhaps by priority, perhaps by component You can do this now, create a saved filter and then use the filter portlet on your dashboard to view the issues that match. If we were actually using Confluence to render dynamic pages, then we could embed that same portlet into a page so that everyone can see the same data. W/o you need to login to JIRA and configure a filter and portlet... Maybe we could link to a few pages in cwiki directly... ? --jason
Re: Thoughts on using JIRA more effectively
Matt Hogstrom wrote: John Sisson wrote: 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. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. I agree that people have natural areas of expertise. I am just wary of seeing people marketed as the "Leader of component/team X" by their employers or in articles/books (and they have the JIRA screen to back it up without an explanation of what it really means). What if two people consider themselves experts in a component, AFAIK, JIRA can only have one lead for a component? Will one get upset at the other being chosen as the Lead? How is a lead selected and what is the length of their term. In a perfect world I wouldn't see any problems with this, but I can see some potential issues here. What do others think? John 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. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) I would be happy to put together a page similar to Derby's for review, I'll created GERONIMO-2080 and assigned to myself. John 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
Re: Thoughts on using JIRA more effectively
John Sisson wrote: 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. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. 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. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) 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
Re: Thoughts on using JIRA more effectively
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
Re: Thoughts on using JIRA more effectively
Here's what I'd like: - a prioritized list of stuff I plan to work on for a release (where the priorities are priorities on my list, not necessarily corresponding to severity of problem, etc.) - a list of bugs that *someone* ought to look at for a release - features (and more rarely, bugs) that should be looked at, but not in the current release - features that people have asked for but are not possible in the near term - a screen showing issues with attached patches, perhaps by priority, perhaps by component I don't like a large bucket of issues with no version assigned. It's my feeling that this bucket quickly gets out of control and no one looks at those issues (in part, due to it's size, and in part, because they're not on anyone's radar). If I *do* look at such an issue, I want to put it somewhere, to indicate that it's been reviewed, and when I think it ought to be looked at. I'd definitely be in favor of allocating some time in the immediate post-1.1 time frame for reviewing and fixing the numerous bugs relating to NPEs or terrible error messages if deployment plans are slightly incorrect. It would be great to clean all those out so we could then focus on more important issues for 1.2, etc. Thanks, Aaron 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. 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. 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. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. 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? Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there. This will make releasing a whole lot easier from a goat herding perspective. I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :) Matt
Re: Thoughts on using JIRA more effectively
On 6/2/06, Bryan Noll <[EMAIL PROTECTED]> wrote: I guess the downside to assigning JIRA's to non-committers is that who knows whether the person asking to have the JIRA assigned to him/her is someone who will actually resolve it, or someone who thinks that they would like to and then it doesn't happen. Thoughts? There're several non-committers with assigned issues to them so it's worked pretty well so for. Of course, there's some risk that a non-committer would leave an issue assigned without being able to spend some time working on it, but it hasn't happened yet. We trust our community and haven't introduced any procedures to work it out other than helping out and assiging the issue to one of us committers with a note it's worked on and after a period of a sustained contribution the non-committer is included in geronimo-noncommitters group to be able to assign issues to hirself. Just say hello and let us know you're looking into an issue and we'll take greater care to not re-assign it to us, committers. Comment the issue you're at that it's already occupied, too. Just for the record. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Thoughts on using JIRA more effectively
So... an observation from a non-committer. If there's a JIRA that a non-committer would like to fix, can that non-committer be assigned the JIRA? I ask because the prospect of diving into something, spending several hours on it, and submitting a patch only to find out that in the meantime, another non-committer had been working on it and got their patch in does not sound very appealing to me. I guess the downside to assigning JIRA's to non-committers is that who knows whether the person asking to have the JIRA assigned to him/her is someone who will actually resolve it, or someone who thinks that they would like to and then it doesn't happen. Thoughts? Jacek Laskowski wrote: On 6/2/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: 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? What I wish to happen is to report new issues unassigned and then whoever wants to work on it assigns it to hirself. I think it always worked pretty well with some exceptions, and there were some talks about re-assigning when someone stepped on and meant to work on an issue that had already been assigned. I understand that it's much harder to newcomers to re-assign than just assign an issue, so I like your idea to *not* assign an issue upfront. Just leave it until someone finds to be able to tackle it. Matt Jacek
Re: Thoughts on using JIRA more effectively
On 6/2/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: 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? What I wish to happen is to report new issues unassigned and then whoever wants to work on it assigns it to hirself. I think it always worked pretty well with some exceptions, and there were some talks about re-assigning when someone stepped on and meant to work on an issue that had already been assigned. I understand that it's much harder to newcomers to re-assign than just assign an issue, so I like your idea to *not* assign an issue upfront. Just leave it until someone finds to be able to tackle it. Matt Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Thoughts on using JIRA more effectively
Can we mark some of the older M* builds are archived? That will help make the "Raised In Versions (non-archived))" portlet more useful.I'm curious... has everyone setup their JIRA home/dashboard to show more details specific to Geronimo... if not, I'd recommend creating a new "Geronimo" portal page and add project portlet for Geronimo, and probably a few project statistic portlets (like "Raised In Versions (non-archived))").I pinged infrastructure about possibly upgrading JIRA, the newer version has some good features that will help us. I'm also going to ask them if we can get the Toolkit plugin installed and configured, as this has some really helpful additions (like one that will color older outstanding issues different, and another that will show all of the folks that participated in the issue).--jasonOn Jun 2, 2006, at 9:52 AM, Matt Hogstrom 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.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.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.For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc.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?Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there.This will make releasing a whole lot easier from a goat herding perspective.I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :)Matt
Re: Thoughts on using JIRA more effectively
Have we considered using the voting system built into JIRA to figure out which JIRAs should really get attention? Sometimes when I have a few spare cycles I'll go looking for JIRAs to fix and this additional metric would help me choose. It would also give us an additional way to listen to the user community. Maybe a few weeks before a release an announcement could get sent to the user list inviting people to vote. Paul 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. 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. 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. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. 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? Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there. This will make releasing a whole lot easier from a goat herding perspective. I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :) Matt
Re: Thoughts on using JIRA more effectively
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. 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. 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? 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. Hen
Thoughts on using JIRA more effectively
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. 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. 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. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. 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? Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there. This will make releasing a whole lot easier from a goat herding perspective. I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :) Matt
