From neugens.limasoftware at gmail.com Thu Dec 1 18:27:09 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 1 Dec 2011 19:27:09 +0100 Subject: OpneJFX mailing lists and project page Message-ID: Hello all, I can't find the address for the OpenJFX project and especially the mailing list. The only reference on http://openjdk.java.net/projects is about the "external" official JavaFX . Are those already open? I would also like to know if there is already some kind of timeline for the first code drop. Thanks, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mark.reinhold at oracle.com Thu Dec 1 18:39:58 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Dec 2011 10:39:58 -0800 Subject: OpneJFX mailing lists and project page In-Reply-To: neugens.limasoftware@gmail.com; Thu, 01 Dec 2011 19:27:09 +0100; Message-ID: <20111201183958.5CD6516D4@eggemoggin.niobe.net> 2011/12/1 10:27 -0800, neugens.limasoftware at gmail.com: > I can't find the address for the OpenJFX project and especially the > mailing list. They should appear later today. - Mark From neugens.limasoftware at gmail.com Thu Dec 1 18:57:41 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 1 Dec 2011 19:57:41 +0100 Subject: OpneJFX mailing lists and project page In-Reply-To: <20111201183958.5CD6516D4@eggemoggin.niobe.net> References: <20111201183958.5CD6516D4@eggemoggin.niobe.net> Message-ID: Il giorno 01/dic/2011, alle ore 19:39, mark.reinhold at oracle.com ha scritto: > 2011/12/1 10:27 -0800, neugens.limasoftware at gmail.com: >> I can't find the address for the OpenJFX project and especially the >> mailing list. > > They should appear later today. > > - Mark Hi Mark, Later *today*, wow this is cool indeed (I was expecting more a reply like: "we're working on it"). Thanks a lot, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From donald.smith at oracle.com Mon Dec 5 14:49:28 2011 From: donald.smith at oracle.com (Donald Smith) Date: Mon, 05 Dec 2011 09:49:28 -0500 Subject: Patent Grant In-Reply-To: <4ECD448F.7080004@oracle.com> References: <4ECA454B.10507@abpni.co.uk> <1321989788.4342.7.camel@springer.wildebeest.org> <4ECC16C9.1080302@abpni.co.uk> <1321998507.4342.9.camel@springer.wildebeest.org> <4ECD448F.7080004@oracle.com> Message-ID: <4EDCD9F8.4030500@oracle.com> A quick update -- I have what I believe is the final draft ready to go -- should be just a very short period of time to go -- thanks for not kicking me too hard, and apologies again for delays... - Don On 23/11/2011 2:07 PM, Donald Smith wrote: > It's coming, I'm really sorry it's taken so long, there's no excuse. > No big changes to what's in 6, just having a hard time getting the > final bits of attention. I'll keep kicking, and please keep kicking me. > > - Don > > On 22/11/2011 4:48 PM, Mark Wielaard wrote: >> Not that I know. At least, there is no field of use restriction in >> "OpenJDK Community TCK License Agreement for Java SE 6" from >> http://openjdk.java.net/legal/ but I see there is still not one for 7. >> Anybody know what happened to that? From aph at redhat.com Mon Dec 5 15:07:36 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 05 Dec 2011 15:07:36 +0000 Subject: Patent Grant In-Reply-To: <4EDCD9F8.4030500@oracle.com> References: <4ECA454B.10507@abpni.co.uk> <1321989788.4342.7.camel@springer.wildebeest.org> <4ECC16C9.1080302@abpni.co.uk> <1321998507.4342.9.camel@springer.wildebeest.org> <4ECD448F.7080004@oracle.com> <4EDCD9F8.4030500@oracle.com> Message-ID: <4EDCDE38.40801@redhat.com> On 12/05/2011 02:49 PM, Donald Smith wrote: > A quick update -- I have what I believe is the final draft ready to go > -- should be just a very short period of time to go -- thanks for not > kicking me too hard, and apologies again for delays... :-) Andrew. From donald.smith at oracle.com Fri Dec 9 13:46:51 2011 From: donald.smith at oracle.com (Donald Smith) Date: Fri, 09 Dec 2011 08:46:51 -0500 Subject: Patent Grant In-Reply-To: <4EDCDE38.40801@redhat.com> References: <4ECA454B.10507@abpni.co.uk> <1321989788.4342.7.camel@springer.wildebeest.org> <4ECC16C9.1080302@abpni.co.uk> <1321998507.4342.9.camel@springer.wildebeest.org> <4ECD448F.7080004@oracle.com> <4EDCD9F8.4030500@oracle.com> <4EDCDE38.40801@redhat.com> Message-ID: <4EE2114B.1010606@oracle.com> Unfortunately I don't have any progress to report - it's still going to be at least a few more days. - Don On 05/12/2011 10:07 AM, Andrew Haley wrote: > On 12/05/2011 02:49 PM, Donald Smith wrote: >> A quick update -- I have what I believe is the final draft ready to go >> -- should be just a very short period of time to go -- thanks for not >> kicking me too hard, and apologies again for delays... > > > :-) > > Andrew. > From mark at klomp.org Sun Dec 11 13:06:50 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 11 Dec 2011 14:06:50 +0100 Subject: Call for participation: Free Java @ FOSDEM 2012 Message-ID: <20111211130650.GD7625@toonder.wildebeest.org> We are pleased to announce the Call for Participation in the FOSDEM 2012 Free Java DevRoom! This marks the 9th year that the Free Java DevRoom has been a part of FOSDEM. http://fosdem.org/2012/ Saturday 4th and Sunday 5th of February 2012 Brussels, Belgium The Free Java DevRoom has become unique in that it has attracted upstream, downstream, distrbutors and and Free Software hackers together in one venue. Topics range from the "deep technical" to "deep community". Join us for this year's theme: "Free Java Momentum" Check out our wiki for more details on the conference: http://wiki.debian.org/Java/DevJam/2012/Fosdem And join the freejava-devroom at lists.fosdem.org https://lists.fosdem.org/mailman/listinfo/freejava-devroom Please submit one (or more) 30 minute talk proposal(s) by the 30th of December 2011 to fosdem at developer.classpath.org. A template for submitting a talk can be found at: http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation Please join us! --The Free Java DevRoom Organizing Committee Andrew Haley, Red Hat Dalibor Topic, Oracle Dr Andrew John Hughes, Red Hat Mark Wielaard, IcedTea Sylvestre Ledru, Debian Tom Marble, Informatique p.s. We had some nice media coverage last year... FLOSS Weekly 152: FOSDEM http://twit.tv/floss152 Linux Outlaws 191 - Special: FOSDEM Coverage http://old.linuxoutlaws.com/podcast/191 From terminatorul at gmail.com Tue Dec 13 16:21:46 2011 From: terminatorul at gmail.com (Timothy Madden) Date: Tue, 13 Dec 2011 18:21:46 +0200 Subject: Is there a better alternative for -cp/CLASSPATH ? Message-ID: Hello Is there a way to launch java applications (classes), without having to know and to specify where the .class files are installed all the time ? Currently I have to set CLASSPATH or use the -classpath option on the java command line every time I want to start a Java application (I hear it is recomanded I do not set CLASSPATH in advance, but instead set it, or use -cp, upon every invocation of java; this way every Java application is invoked with its own CLASSPATH). Is there no way I could type just: `java net.grinder.Grinder? without having to specify the installation files/directory for The Grinder ? Is there no such thing as a local registry/repository/catalog of installed java classes/jars, that the launcher could use ? Thank you, Timothy Madden From aph at redhat.com Tue Dec 13 17:50:33 2011 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Dec 2011 17:50:33 +0000 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: References: Message-ID: <4EE79069.3040707@redhat.com> On 12/13/2011 04:21 PM, Timothy Madden wrote: > Is there no such thing as a local registry/repository/catalog of > installed java classes/jars, that the launcher could use ? This is one of the goals of Project Jigsaw: http://openjdk.java.net/projects/jigsaw/ Andrew. From iris.clark at oracle.com Tue Dec 13 19:39:25 2011 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 13 Dec 2011 11:39:25 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow Message-ID: Hi! I'm defining requirements for the OpenJDK bug database [1]. As one would guess, it's not easy. We have more than 15 years of data, process evolution, and supporting tools that we need to consider. Opinions on the effectiveness of existing process and tools vary. Many people with different roles (end-users, developers, quality, release management, etc.) need to be able to access the system. I've written a preliminary draft of what the pilot workflow for bugs and RFEs might look like. It is based on the existing bug system with modifications to omit portions that aren't used. There is no requirement that we stick closely to this draft, though any changes will need to consider the impact on data migration. It still needs quite a bit of work. http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html Please send feedback/comments to this mailing list. I'll provide regular updates as feedback is incorporated and I fill in other sections of the document. Thanks, iris [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html From david.holmes at oracle.com Wed Dec 14 02:39:04 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2011 12:39:04 +1000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EE80C48.7060406@oracle.com> Hi Iris, A few initial comments. The description for state "Understood" in the transition from dispatched was not at all what I would expect: "This bug is either something which will be fixed as part of other work currently being conducted (but not quite a duplicate) or this bug was created specifically to describe planned changes." ??? Later descriptions of "understood" seem more in line with today's meaning. Though where it says; "Sufficient investigation has been preformed to gain a basic understanding of how this bug/feature request should be addressed. There is no requirement that an actual solution be known at this time." this matches more with "Cause known" than "Fix Understood". I really like what we currently have in terms of: - cause known (problem has been identified) - fix understood (a solution seems to have been devised) - fix in progress (actively implementing the solution) As an IE (and someone who watches many new bug reports) I will often take a bug to "cause known" as part of my initial eval. Combining an understanding of the problem with the discovery of a solution into one state loses very important information in my opinion. For example, a bug with an understood fix can be easily picked up by a new developer as a "starter" bug. I don't think "closed: future project" works very well. Once a bug is closed it should remain closed in my view. Maybe a new substatus of "accepted" could be "future project" to indicate deferral? I'd even like to see two different "closed" states to represent the two cases: a change was made, and a change was not made - that makes it easier to actually search for CRs that have been fixed in particular categories. Not sure about the "not accepted" status. Seems applicable to RFEs more than bugs (a bug is either a bug or not). Even for RFE's it's not clear the IE is in a position to make that judgment call. Further, RFE's of a non-minor nature will come through as JEPs. For "will not fix" we might clarify the reasoning eg: too risky for a given release (ie not backporting from 8 to 7); causes unacceptable incompatibilities; etc. That's all for now. Cheers, David Holmes On 14/12/2011 5:39 AM, Iris Clark wrote: > Hi! > > I'm defining requirements for the OpenJDK bug database [1]. As one > would guess, it's not easy. We have more than 15 years of data, > process evolution, and supporting tools that we need to consider. > Opinions on the effectiveness of existing process and tools vary. > Many people with different roles (end-users, developers, quality, > release management, etc.) need to be able to access the system. > > I've written a preliminary draft of what the pilot workflow for bugs > and RFEs might look like. It is based on the existing bug system with > modifications to omit portions that aren't used. There is no > requirement that we stick closely to this draft, though any changes > will need to consider the impact on data migration. It still needs > quite a bit of work. > > http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html > > Please send feedback/comments to this mailing list. I'll provide > regular updates as feedback is incorporated and I fill in other > sections of the document. > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html From volker.simonis at gmail.com Wed Dec 14 08:39:30 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 14 Dec 2011 09:39:30 +0100 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: Hi Iris, nice to hear that somebody is working on this. I have some questions around end user / external user access to the new system: 1. Who will be able to open a new bug/RFE? a. everybody b. registered users only (with some trivial click-trough registration) c. only special roles as defined in the OpenJDK bylaws (i.e. Participants, Contributors, Authors, Committers, Members..) I would strongly vote for variant a. or b. but if you choose variant c. at least every "Participant" (i.e. everybody who subscribed to an OpenJDK mailing list) should be able to open new bugs/RFEs. 2. Who will be able to change bugs/RFEs? This is somewhat related to question 1. Of course I understand that this will have to be handled more restrictive, but at least commenting on a bug should be handled as liberal as possible (i.e. at least as liberal as in the answer for 1). 3. Will it be possible to "subscribe" to a bug/RFE in order to get notified of any changes? Again a crucial feature for me which should be handled as liberal as possible. The author of a bug should be placed automatically on the subscription list (which would of course require some kind of registration - e.g. with the credentials of a "Participants") 4. Will newly entered bugs/RFEs be immediately visible with a valid, immutable Bug ID (i.e. will they have status "Dispatched") - As you probably all know, currently new bugs filed from outside Oracle only get a temporary Bug ID until they are evaluated and promoted by somebody inside Oracle (which can take weeks..). I think this is simply a "no-go" for a real open source project. - Even bugs filed by Oracle employees need a day or more until they become publicly visible. Will this improve with the new system? Regards and please keep on pushing this, Volker On Tue, Dec 13, 2011 at 8:39 PM, Iris Clark wrote: > Hi! > > I'm defining requirements for the OpenJDK bug database [1]. ?As one > would guess, it's not easy. ?We have more than 15 years of data, > process evolution, and supporting tools that we need to consider. > Opinions on the effectiveness of existing process and tools vary. > Many people with different roles (end-users, developers, quality, > release management, etc.) need to be able to access the system. > > I've written a preliminary draft of what the pilot workflow for bugs > and RFEs might look like. ?It is based on the existing bug system with > modifications to omit portions that aren't used. ?There is no > requirement that we stick closely to this draft, though any changes > will need to consider the impact on data migration. ?It still needs > quite a bit of work. > > ?http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html > > Please send feedback/comments to this mailing list. ?I'll provide > regular updates as feedback is incorporated and I fill in other > sections of the document. > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html From mthornton at optrak.com Wed Dec 14 09:39:49 2011 From: mthornton at optrak.com (Mark Thornton) Date: Wed, 14 Dec 2011 09:39:49 +0000 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: References: Message-ID: <4EE86EE5.50305@optrak.com> On 13/12/11 16:21, Timothy Madden wrote: > Hello > > Is there a way to launch java applications (classes), without having > to know and to specify where the .class files are installed all the > time ? > > Currently I have to set CLASSPATH or use the -classpath option on the > java command line every time I want to start a Java application (I > hear it is recomanded I do not set CLASSPATH in advance, but instead > set it, or use -cp, upon every invocation of java; this way every > Java application is invoked with its own CLASSPATH). > > Is there no way I could type just: > `java net.grinder.Grinder? > without having to specify the installation files/directory for The > Grinder ? > > Is there no such thing as a local registry/repository/catalog of > installed java classes/jars, that the launcher could use ? > > Thank you, > Timothy Madden > You can use the Class-Path entry in the manifest of the main jar file (along with the Main-Class attribute). This works best if the additional jar files are located relative to the main jar file. Mark Thornton From fcassia at gmail.com Wed Dec 14 10:00:26 2011 From: fcassia at gmail.com (Fernando Cassia) Date: Wed, 14 Dec 2011 07:00:26 -0300 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: References: Message-ID: On Tue, Dec 13, 2011 at 13:21, Timothy Madden wrote: > Is there a way to launch java applications (classes), without having to know > and to specify where the .class files are installed all the time ? Yes, One-Jar. My favorite Java apps (desktop Java) are properly packaged as a single .jar file and can be run by just issuing java -jar appname.jar. I think Sun should have made One-Jar part of the JDK and its use mandatory. http://one-jar.sourceforge.net/ Fiddling with the classpath feels so 1990s... FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code From martijnverburg at gmail.com Wed Dec 14 10:40:38 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 14 Dec 2011 10:40:38 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: Hi Iris, Awesome that this is being worked on and I know defining these workflows can be a bit of a thankless task :-). I'm going to approach it from a slightly different angle, but this angle is really dependant on who has access to the bug database (as Volker mentions). I'm assuming the general public, assuming they have a login so the original submitter can be contacted. The proposed workflow is great because it does two important things: 1.) It makes it really easy to migrate the existing data 2.) Existing OpenJDK committers will be able to understand it easily However, some of the naming is not what I've seen commonly used on projects, and there's therefore a risk that outsiders (i.e. The general public, which are likely to be your most numerous user) are going to misinterpret the statuses and cause havoc like a pack of Otters. --- My suggestion is to compromise and enhance the naming of these statuses so that they're in line with the more common nomenclature used in many projects today. This could be done either via a description or the use of a subtext. So perhaps: Dispatched --> Dispatched (Open/Opened/Reopened) Accepted --> Accepted (Verified) Understood --> I share the same reservations as David on this one, I don't think Understood is clear In JIRA you can link issues either as parent/children or as siblings, so having a status that indicates it's part of another fix is not necessary. Fix in Progress --> Fix In Progress Fixed --> Fixed (Resolved) Closed --> (Closed) Incomplete --> I'm not sure if this is required? Typically a Bug or RFE will stay in an Open status until it it gets the details it needs. The Assigned To field and the comments are usually sufficient to point out that someone is expected to give information before moving the issue on. Often a rule can be put in place to auto-close open issues after X days if original submitter does not supply extra information, e.g. Closed (Not Reproducible or Insufficient Information given). --- I'm also a little confused about the QA steps setting closed sub statuses. I'm more used to a workflow where a bug or RFE is Resolved and then only Closed once the fix has been tested/verified. Sometimes a Closed issue does in fact not fix the problem, in that case it can be either OK to ReOpen that issue or submit a new issue and link it to the old one. --- That's my 2c for now, overall I think it's a great start and that I'm glad you've thought carefully about the migration aspects. Thanks again for working on this! Cheers, Martijn On 14 December 2011 08:39, Volker Simonis wrote: > Hi Iris, > > nice to hear that somebody is working on this. > > I have some questions around end user / external user access to the new system: > > 1. Who will be able to open a new bug/RFE? > ?a. everybody > ?b. registered users only (with some trivial click-trough registration) > ?c. only special roles as defined in the OpenJDK bylaws (i.e. > Participants, Contributors, Authors, Committers, Members..) > > I would strongly vote for variant a. or b. but if you choose variant > c. at least every "Participant" (i.e. everybody who subscribed to an > OpenJDK mailing list) should be able to open new bugs/RFEs. > > 2. Who will be able to change bugs/RFEs? > > This is somewhat related to question 1. Of course I understand that > this will have to be handled more restrictive, but at least commenting > on a bug should be handled as liberal as possible (i.e. at least as > liberal as in the answer for 1). > > 3. Will it be possible to "subscribe" to a bug/RFE in order to get > notified of any changes? > > Again a crucial feature for me which should be handled as liberal as > possible. The author of a bug should be placed automatically on the > subscription list (which would of course require some kind of > registration - e.g. with the credentials of a "Participants") > > 4. Will newly entered bugs/RFEs be immediately visible with a valid, > immutable Bug ID (i.e. will they have status "Dispatched") > ?- As you probably all know, currently new bugs filed from outside > Oracle only get a temporary Bug ID until they are evaluated and > promoted by somebody inside Oracle (which can take weeks..). I think > this is simply a "no-go" for a real open source project. > ?- Even bugs filed by Oracle employees need a day or more until they > become publicly visible. Will this improve with the new system? > > Regards and please keep on pushing this, > Volker > > On Tue, Dec 13, 2011 at 8:39 PM, Iris Clark wrote: >> Hi! >> >> I'm defining requirements for the OpenJDK bug database [1]. ?As one >> would guess, it's not easy. ?We have more than 15 years of data, >> process evolution, and supporting tools that we need to consider. >> Opinions on the effectiveness of existing process and tools vary. >> Many people with different roles (end-users, developers, quality, >> release management, etc.) need to be able to access the system. >> >> I've written a preliminary draft of what the pilot workflow for bugs >> and RFEs might look like. ?It is based on the existing bug system with >> modifications to omit portions that aren't used. ?There is no >> requirement that we stick closely to this draft, though any changes >> will need to consider the impact on data migration. ?It still needs >> quite a bit of work. >> >> ?http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html >> >> Please send feedback/comments to this mailing list. ?I'll provide >> regular updates as feedback is incorporated and I fill in other >> sections of the document. >> >> Thanks, >> iris >> >> [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html From Alan.Bateman at oracle.com Wed Dec 14 12:34:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Dec 2011 12:34:59 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EE897F3.8060308@oracle.com> On 13/12/2011 19:39, Iris Clark wrote: > : > > I've written a preliminary draft of what the pilot workflow for bugs > and RFEs might look like. It is based on the existing bug system with > modifications to omit portions that aren't used. There is no > requirement that we stick closely to this draft, though any changes > will need to consider the impact on data migration. It still needs > quite a bit of work. > > http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html > > Please send feedback/comments to this mailing list. I'll provide > regular updates as feedback is incorporated and I fill in other > sections of the document. > Iris - just a couple of initial comments/questions: Not strictly workflow related but can you expand a bit on the "where" list mentioned in the description of Fixed? This is clearly very important when changes accumulated in integration forests are pushed to master but less critical (in my view) when changes propagate to other integration forests. I would also suggest that our collection of integration forests isn't fixed and will change over time so it's not completely clear to me how in sync the "where" will be. The quality function is currently mentioned as moving bugs from Fixed to Closed. I will think it will be great to have quality folks working openly in OpenJDK and I'm just wondering if this need to be separated out into a different role for the purposes of work flow. Same thing for the integrator function who I will assume be responsible for ensuring that the bug database is updated when changes are pushed to the master forests. The sub-statuses on Closed seem too generous to me. I will guess that having the choice of "Not a Bug", "Not Accepted", and "Not our bug" will lead to minor spats. In terms of transitions then I assume it will be possible to change these at any time - for example if someone incorrectly closes a bug with substatus Fix Failed then I assume we can change it in the event that it's just a misunderstanding. Understood: In Dispatched description it describes Understood as: " This bug is either something which will be fixed as part of other work currently being conducted (but not quite a duplicate) or this bug was created specifically to describe planned changes.". Later in the "Understood" section it defines it as "Sufficient investigation has been preformed to gain a basic understanding of how this bug/feature request should be addressed. There is no requirement that an actual solution be known at this time". The latter is closer to what I would expect it to mean. I look forward to seeing the Multi-Release section expanded. That's critical to how we work in OpenJDK. -Alan From kelly.ohair at oracle.com Wed Dec 14 17:41:09 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 14 Dec 2011 09:41:09 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <370EE917-4A9F-4DCB-89A5-607E91334373@oracle.com> Our management and my own preference on bug assignment is that engineers should only be assigned to the bugs/rfes that they are actually working on. I know this has been different for different teams, I have always found it silly to have one engineer hundreds of bugs assigned to him, some for many many years, seems depressing to me. Certainly at "Fix in Progress", an assigned engineer would be a requirement. --- I'm ok with our traditional Defer and Fix Failed going away, seemed silly to me. But "Fix Available" and "Fix Delivered" getting folded into Fixed... Maybe that would be ok if there was some kind of field to say where the fix was pushed to? Also might be nice to know who pushed the changeset to where, but for the state just "Fixed" would be fine. -- Spelling: "Quality can ont verify" --- The paragraphs in the "Goes to..." section seemed to confuse things for me. The section is good, and the 'typical progression' and 'rare' annotations were very helpful, but the paragraphs just seemed to duplicate the information under that state. -kto From joe.darcy at oracle.com Wed Dec 14 19:28:37 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Dec 2011 11:28:37 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EE8F8E5.2040901@oracle.com> Hi Iris. Thanks for sending this draft out. To add to some of the discussions that have already occurred around possible workflows, rather than being a pure boolean value, the fixed state could have, say a set of URLs associated with it. The URLs could be pointers to the Hg changesets comprising to the fix. (The Sun legacy bug system had different states for "fixed available"/"fixed" and "fixed delivered"/"integrated." A bug is considered fixed when it is pushed to a staging repository like TL and a bug is considered integrated when it hits the master repository. So the old bug state model implicitly assumes two levels of managed repositories, which is not always a valid assumption. For example, for OpenJDK 6, we only have a one-level master repository so the fixed state on an OpenJDK 6 bug was an invalid condition. Since the fixed and integrated states differ only in *where* the fix is present, I think modeling that fact more directly in the set of states is preferable.) If a fixed state with URLs is decided upon, it would be convenient if the Hg push hooks for the repositories automatically updated the bug with the changeset URL. Some other comments on the state model. There may be value in having a new "resolved" state with "verified" and "unverified" substates. With those states, the usual sets of transitions would be dispatched -> accepted -> understood -> fix in progress -> fixed -> resolved The state model influences what is easy to query for. As one of the many masters of a bug system, as an engineer I'd like the following query to be very easy to issue: what is the set of issues that were successfully resolved in a release because of code changes on my part? Having multiple substates of "closed" corresponding to this situation complicates the query. (Again commenting on the legacy JDK bug system, previously "integrated" was the expected terminal state of a successful bug fix. However, more recently the quality team is supposed to verify whether or not fixes are present and valid so the expected terminal state is now "closed - verified" or sometimes "closed - unverified", which is inconvenient to query for in some of the main tools used to work with the bug system.) If the fix failed state is going to be kept, having it as a substate of closed is better than preserving it as its own state. Given the jcheck rules against reusing bug ids, if a fix has failed, a new bug has to be filed to resolve the problem. Cheers, -Joe On 12/13/2011 11:39 AM, Iris Clark wrote: > Hi! > > I'm defining requirements for the OpenJDK bug database [1]. As one > would guess, it's not easy. We have more than 15 years of data, > process evolution, and supporting tools that we need to consider. > Opinions on the effectiveness of existing process and tools vary. > Many people with different roles (end-users, developers, quality, > release management, etc.) need to be able to access the system. > > I've written a preliminary draft of what the pilot workflow for bugs > and RFEs might look like. It is based on the existing bug system with > modifications to omit portions that aren't used. There is no > requirement that we stick closely to this draft, though any changes > will need to consider the impact on data migration. It still needs > quite a bit of work. > > http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html > > Please send feedback/comments to this mailing list. I'll provide > regular updates as feedback is incorporated and I fill in other > sections of the document. > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html From iris.clark at oracle.com Wed Dec 14 20:01:14 2011 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 14 Dec 2011 12:01:14 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE80C48.7060406@oracle.com> References: Message-ID: Hi, David. First, thanks for taking the time to read the document and provide comments. You've hit on some of the more difficult areas that I was hoping would come up. > The description for state "Understood" in the transition from dispatched was > not at all what I would expect: > > "This bug is either something which will be fixed as part of other work > currently being conducted (but not quite a duplicate) or this bug was > created specifically to describe planned changes." > > ??? Later descriptions of "understood" seem more in line with today's > meaning. Oops. I thought I'd fixed all of those. The text you quote should be replaced with something that's closer to other descriptions of "understood". I'll align this to match the others in the next draft. > Though where it says; > > "Sufficient investigation has been preformed to gain a basic understanding > of how this bug/feature request should be addressed. There is no requirement > that an actual solution be known at this time." > > this matches more with "Cause known" than "Fix Understood". The definition I provided does not adequately describe what one should expect for this status; hence my question immediately after that line: "The definition of this status should match the current definition/expectation for "Fix Understood". What is that definition? Is it sufficient to remove the final sentence? Perhaps it should be replaced with a recommended confidence level? "Sufficient investigation has been preformed to gain a basic understanding of how this bug/feature request should be addressed and the associated risks." > I really like what we currently have in terms of: > - cause known (problem has been identified) > - fix understood (a solution seems to have been devised) > - fix in progress (actively implementing the solution) > > As an IE (and someone who watches many new bug reports) I will often take a > bug to "cause known" as part of my initial eval. Combining an understanding > of the problem with the discovery of a solution into one state loses very > important information in my opinion. For example, a bug with an understood > fix can be easily picked up by a new developer as a "starter" bug. I agree that when we remove statuses, information may be lost. I had combined these two statuses because my impression was that they were not currently being used effectively. What seems to happen in many cases is that once sufficient investigation has been done to identify the cause, the recommendation for a solution would be known as well). What experience do other people have with these statuses? > I don't think "closed: future project" works very well. Once a bug is > closed it should remain closed in my view. Maybe a new substatus of > "accepted" could be "future project" to indicate deferral? Ok. First let's clarify that the existing BT "Defer" status does NOT correspond to the "deferral process" that's implemented by release management during late stages of the release cycle. (I expect those "deferrals" to be covered by a separate "Approval Workflow".) At least for JDK releases, the existing BT "Defer" status is very rarely used. I speculate that's because historically we've been strongly advised against use. Over time, it appears that use has crept in. Don't quote me on the numbers but I think we're talking about <400 bugs out of >200,000. Some of those bugs have been in "Defer" for years. This is a fantastic way for bugs to drop off our radar indefinitely as there is no expectation that there be periodic review of anything that lands there. Of the existing 6 substatus ("Future Project", "Code Freeze", "No Plan to Fix", "No Resources Available", "Too Risky to Fix", "None"), "Future Project" appears to be used the most. It is often associated with bugs which some people would have closed because at the time of the bug's submission the work was entirely out of scope. However, in some cases the IE left it open with the expectation that the idea is valid and was within the realm of possibility. I moved these bugs to "Closed: Future Project", because in those cases, it seemed to be a more honest evaluation of the likelihood of the work getting done and our current lack of review for those bugs. It also allows us the possibility of quickly finding that kind of long-term, innovative ideas. So, getting back to the issue at hand. What should we do with what I've currently defined as "Closed: Future Project"? There are at least 3 possibilities: - New "Accepted: Future Project" as you suggest. We would need to define a lifecycle for these bugs (periodic review, etc.) so that that don't stay there indefinitely. - New "Closed: Future Project", as currently defined. - Decide that the bug system is not the right place to store these kinds of innovative ideas (perhaps JEP is). Future submissions of this type moved to "Closed: Will Not Fix" and evaluation recommends that a JEP be filed. Move all existing "Defer: Future Project" bugs to "Closed: Will not Fix". - Other? > I'd even > like to see two different "closed" states to represent the two cases: > a change was made, and a change was not made - that makes it easier to > actually search for CRs that have been fixed in particular categories. The source for the information you really want about whether a fix has been applied should come from the source control system, not the bug system. That's the only information you can really trust. > Not sure about the "not accepted" status. Seems applicable to RFEs > more than bugs (a bug is either a bug or not). Even for RFE's it's not > clear the IE is in a position to make that judgment call. Further, > RFE's of a non-minor nature will come through as JEPs. Agreed. Perhaps we should just remove it entirely? Objections? > For "will not fix" we might clarify the reasoning eg: too risky for a > given release (ie not backporting from 8 to 7); causes unacceptable > incompatibilities; etc. I suspect that there are too many possibilities. Could this reasoning be provided as part of the evaluation? Thanks again! iris From iris.clark at oracle.com Wed Dec 14 20:39:11 2011 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 14 Dec 2011 12:39:11 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: Hi, Volker. > nice to hear that somebody is working on this. Thanks! > I have some questions around end user / external user access to the new > system: > > 1. Who will be able to open a new bug/RFE? > a. everybody > b. registered users only (with some trivial click-trough registration) > c. only special roles as defined in the OpenJDK bylaws (i.e. Participants, > Contributors, Authors, Committers, Members..) > > I would strongly vote for variant a. or b. but if you choose variant c. at > least every "Participant" (i.e. everybody who subscribed to an OpenJDK mailing > list) should be able to open new bugs/RFEs. Right now, bugs.sun.com requires (b), minimal registration. There are some who believe that that bar is too high and would prefer (a). (c) is not on the table. > 2. Who will be able to change bugs/RFEs? > > This is somewhat related to question 1. Of course I understand that this will > have to be handled more restrictive, but at least commenting on a bug should > be handled as liberal as possible (i.e. at least as liberal as in the answer > for 1). Define what you mean by "change"? - Provide a comment similar to what we have on bugs.sun.com? As you speculated, the answer would depend on what is decided for your first question. - Provide an evaluation, update the bug's status, and other development activities? All OpenJDK Committers will need to be able to update bugs. OpenJDK Authors may also be able to make limited set of changes as appropriate for their role as Author. (I plan to provide more details when I get to the "Roles" section of the document.) > 3. Will it be possible to "subscribe" to a bug/RFE in order to get notified of > any changes? > > Again a crucial feature for me which should be handled as liberal as > possible. The author of a bug should be placed automatically on the > subscription list (which would of course require some kind of registration - > e.g. with the credentials of a "Participants") Yes. JIRA provides mechanisms to vote on bugs and receive notifications. Both of these options will be available to the set of users identified by the answer to question 1. > 4. Will newly entered bugs/RFEs be immediately visible with a valid, immutable > Bug ID (i.e. will they have status "Dispatched") > - As you probably all know, currently new bugs filed from outside Oracle only > get a temporary Bug ID until they are evaluated and promoted by somebody > inside Oracle (which can take weeks..). I think this is simply a "no-go" > for a real open source project. > - Even bugs filed by Oracle employees need a day or more until they become > publicly visible. Will this improve with the new system? All newly entered bugs/RFEs will be immediately visible. Bugs submitted by OpenJDK Committers will be part of the Developer Workflow. I am currently investigating how we should handle end-user bugs (bugs which are entered in bugs.sun.com). It is clear that they'll also be immediately visible; however, because those bugs tend to require more heavy triage, I'm exploring the idea of having them in another JIRA project with parallel ontology. This would allow us to provide a workflow which is customized to their triage needs and to provide the additional guidance end-users already have when submitting bugs via bugs.sun.com. Thanks, iris From omajid at redhat.com Wed Dec 14 23:21:23 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 14 Dec 2011 18:21:23 -0500 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE8F8E5.2040901@oracle.com> References: <4EE8F8E5.2040901@oracle.com> Message-ID: <4EE92F73.2090601@redhat.com> Hi Joe, On 12/14/2011 02:28 PM, Joe Darcy wrote: > If a fixed state with URLs is decided upon, it would be convenient if > the Hg push hooks for the repositories automatically updated the bug > with the changeset URL. > I think useful information like this would be nice to have irrespective of whether we use a fixed state with URLs or not. We do something similar in fedora. Whenever I push out a package which claims to fix a bug, a comment is added to the bug report that notes where the fix is. For example, the following two comments to the bug report indicate the fix has been pushed to F15 and F16: https://bugzilla.redhat.com/show_bug.cgi?id=741821#c9 https://bugzilla.redhat.com/show_bug.cgi?id=741821#c10 Something like this in the openjdk bug system would point to the changesets which were pushed to one of the openjdk repositories. Thanks, Omair From joe.darcy at oracle.com Wed Dec 14 23:30:56 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Dec 2011 15:30:56 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE92F73.2090601@redhat.com> References: <4EE8F8E5.2040901@oracle.com> <4EE92F73.2090601@redhat.com> Message-ID: <4EE931B0.3010109@oracle.com> Hi Omair, On 12/14/2011 3:21 PM, Omair Majid wrote: > Hi Joe, > > On 12/14/2011 02:28 PM, Joe Darcy wrote: >> If a fixed state with URLs is decided upon, it would be convenient if >> the Hg push hooks for the repositories automatically updated the bug >> with the changeset URL. >> > > I think useful information like this would be nice to have > irrespective of whether we use a fixed state with URLs or not. Yes, I tend to manually add a link to the changest URL for my own bugs. I also often go a step further and include the text of the Hg patch in an internal "Suggested fix" field or include a zip of the webrev as an attachment to the bug. I prefer having some inline information about the contents of the fix stored directly in the bug database to help long-term bug archeology since the lifetime of the JDK bug system may be longer than the lifetime of particular set of servers or URLs. -Joe From weijun.wang at oracle.com Thu Dec 15 02:26:26 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Dec 2011 10:26:26 +0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE8F8E5.2040901@oracle.com> References: <4EE8F8E5.2040901@oracle.com> Message-ID: <4EE95AD2.8090100@oracle.com> > (The Sun legacy bug system had different states for "fixed > available"/"fixed" and "fixed delivered"/"integrated." A bug is > considered fixed when it is pushed to a staging repository like TL and a > bug is considered integrated when it hits the master repository. So the > old bug state model implicitly assumes two levels of managed > repositories, which is not always a valid assumption. For example, for > OpenJDK 6, we only have a one-level master repository so the fixed state > on an OpenJDK 6 bug was an invalid condition. Since the fixed and > integrated states differ only in *where* the fix is present, I think > modeling that fact more directly in the set of states is preferable.) Well, as long as we still have the "Integrated in Build" field and it can be used to locate the exact release/build, the "Fix Delivered" state is not necessary. BTW, I always find the "Fixed in Build" field useless. I would rather like it to be something equivalent to the changeset id. Thanks Max From david.holmes at oracle.com Thu Dec 15 07:13:13 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2011 17:13:13 +1000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EE99E09.3030904@oracle.com> Hi Iris, On 15/12/2011 6:01 AM, Iris Clark wrote: > The definition I provided does not adequately describe what one should expect > for this status; hence my question immediately after that line: > > "The definition of this status should match the current > definition/expectation for "Fix Understood". What is that definition? > > Is it sufficient to remove the final sentence? Perhaps it should be replaced > with a recommended confidence level? > > "Sufficient investigation has been preformed to gain a basic understanding > of how this bug/feature request should be addressed and the associated risks." I really think we need the two statuses: "cause known" and "fix understood" ... > I had combined these two statuses because my impression was that they were not > currently being used effectively. What seems to happen in many cases is that > once sufficient investigation has been done to identify the cause, the > recommendation for a solution would be known as well). That is often the case for simple bugs, but certainly not always. > At least for JDK releases, the existing BT "Defer" status is very rarely > used. I speculate that's because historically we've been strongly advised > against use. Over time, it appears that use has crept in. Don't quote me on > the numbers but I think we're talking about<400 bugs out of>200,000. Some > of those bugs have been in "Defer" for years. This is a fantastic way for > bugs to drop off our radar indefinitely as there is no expectation that there > be periodic review of anything that lands there. I agree that the current Defer is not well applied or understood. In effect if you assign a bug to an indeterminate release it is effectively deferred. So whether a bug is "accepted" or "understood" it could still be deferred in the sense that it is not targeted for a specific future release. > So, getting back to the issue at hand. What should we do with what I've > currently defined as "Closed: Future Project"? There are at least 3 > possibilities: > > - New "Accepted: Future Project" as you suggest. We would need to define a > lifecycle for these bugs (periodic review, etc.) so that that don't stay > there indefinitely. Not sure why staying there indefinitely is an issue, other than cluttering reports. > - New "Closed: Future Project", as currently defined. > > - Decide that the bug system is not the right place to store these kinds of > innovative ideas (perhaps JEP is). Future submissions of this type moved to > "Closed: Will Not Fix" and evaluation recommends that a JEP be filed. Move > all existing "Defer: Future Project" bugs to "Closed: Will not Fix". This begs the question as to the long term management of JEPs. What happens to JEPs that are rejected, do they linger in a JEP repository? > - Other? > >> I'd even >> like to see two different "closed" states to represent the two cases: >> a change was made, and a change was not made - that makes it easier to >> actually search for CRs that have been fixed in particular categories. > > The source for the information you really want about whether a fix has been > applied should come from the source control system, not the bug system. > That's the only information you can really trust. I'm not aware of any way to run queries against mercurial the way we can with BQ and will be able to with Jira. I echo Joe's sentiment that having both resolved and unresolved issues be "closed" makes it harder to find those resolved issues. Doing bug triage is aided immensely if you can query which bugs were fixed in a specific build of a specific release. >> For "will not fix" we might clarify the reasoning eg: too risky for a >> given release (ie not backporting from 8 to 7); causes unacceptable >> incompatibilities; etc. > > I suspect that there are too many possibilities. Could this reasoning be > provided as part of the evaluation? I actually meant this as additional text for the document, to explain the circumstances when "will not fix" might be appropriate. Cheers, David > > Thanks again! > > iris From martijnverburg at gmail.com Thu Dec 15 10:36:28 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 15 Dec 2011 10:36:28 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE931B0.3010109@oracle.com> References: <4EE8F8E5.2040901@oracle.com> <4EE92F73.2090601@redhat.com> <4EE931B0.3010109@oracle.com> Message-ID: Hi Joe, My understanding is that JIRA should be able to hook into mercurial directly so that when you commit a changeset it appears in that ticket item (as long as your commit message references it). Cheers, Martijn On 14 December 2011 23:30, Joe Darcy wrote: > Hi Omair, > > > On 12/14/2011 3:21 PM, Omair Majid wrote: >> >> Hi Joe, >> >> On 12/14/2011 02:28 PM, Joe Darcy wrote: >>> >>> If a fixed state with URLs is decided upon, it would be convenient if >>> the Hg push hooks for the repositories automatically updated the bug >>> with the changeset URL. >>> >> >> I think useful information like this would be nice to have irrespective of >> whether we use a fixed state with URLs or not. > > > Yes, I tend to manually add a link to the changest URL for my own bugs. ?I > also often go a step further and include the text of the Hg patch in an > internal "Suggested fix" field or include a zip of the webrev as an > attachment to the ?bug. > > I prefer having some inline information about the contents of the fix stored > directly in the bug database to help long-term bug archeology since the > lifetime of the JDK bug system may be longer than the lifetime of particular > set of servers or URLs. > > -Joe From volker.simonis at gmail.com Thu Dec 15 13:45:40 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 15 Dec 2011 14:45:40 +0100 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: Hi Iris, please see my comments inline.. On Wed, Dec 14, 2011 at 9:39 PM, Iris Clark wrote: > Hi, Volker. > >> nice to hear that somebody is working on this. > > Thanks! > >> I have some questions around end user / external user access to the new >> system: >> >> 1. Who will be able to open a new bug/RFE? >> ?a. everybody >> ?b. registered users only (with some trivial click-trough registration) >> ?c. only special roles as defined in the OpenJDK bylaws (i.e. Participants, >> ? ? Contributors, Authors, Committers, Members..) >> >> I would strongly vote for variant a. or b. but if you choose variant c. at >> least every "Participant" (i.e. everybody who subscribed to an OpenJDK mailing >> list) should be able to open new bugs/RFEs. > > Right now, bugs.sun.com requires (b), minimal registration. ?There are some > who believe that that bar is too high and would prefer (a). ?(c) is not on the > table. > >> 2. Who will be able to change bugs/RFEs? >> >> This is somewhat related to question 1. Of course I understand that this will >> have to be handled more restrictive, but at least commenting on a bug should >> be handled as liberal as possible (i.e. at least as liberal as in the answer >> for 1). > > Define what you mean by "change"? > > - Provide a comment similar to what we have on bugs.sun.com? > > ?As you speculated, the answer would depend on what is decided for your first > ?question. > > - Provide an evaluation, update the bug's status, and other development > ?activities? > > ?All OpenJDK Committers will need to be able to update bugs. ?OpenJDK Authors > ?may also be able to make limited set of changes as appropriate for their > ?role as Author. > > (I plan to provide more details when I get to the "Roles" section of the > document.) > >> 3. Will it be possible to "subscribe" to a bug/RFE in order to get notified of >> any changes? >> >> Again a crucial feature for me which should be handled as liberal as >> possible. The author of a bug should be placed automatically on the >> subscription list (which would of course require some kind of registration - >> e.g. with the credentials of a "Participants") > > Yes. ?JIRA provides mechanisms to vote on bugs and receive notifications. > Both of these options will be available to the set of users identified by the > answer to question 1. > >> 4. Will newly entered bugs/RFEs be immediately visible with a valid, immutable >> ? ?Bug ID (i.e. will they have status "Dispatched") >> ?- As you probably all know, currently new bugs filed from outside Oracle only >> ? ?get a temporary Bug ID until they are evaluated and promoted by somebody >> ? ?inside Oracle (which can take weeks..). I think this is simply a "no-go" >> ? ?for a real open source project. >> ?- Even bugs filed by Oracle employees need a day or more until they become >> ? ?publicly visible. Will this improve with the new system? > > All newly entered bugs/RFEs will be immediately visible. ?Bugs submitted by > OpenJDK Committers will be part of the Developer Workflow. > > I am currently investigating how we should handle end-user bugs (bugs which > are entered in bugs.sun.com). ?It is clear that they'll also be immediately > visible; however, because those bugs tend to require more heavy triage, I'm > exploring the idea of having them in another JIRA project with parallel > ontology. ?This would allow us to provide a workflow which is customized to > their triage needs and to provide the additional guidance end-users already > have when submitting bugs via bugs.sun.com. > I personally don't think that two parallel JIRA instances will be particularly useful. They will be just a constant cause of confusion. Because eventually you'd have to transfer bugs from the "end-user" bug system to the "real" bug system. And even if you'd somehow manage to keep the bug ids unique between the two systems, you would still have two systems with all the drawbacks: - which system to search (before entering a new bug) - in which system to track the bug - you'll have to keep the bug content in sync between the two systems (otherwise, if you just move the bug from one system to the other, links to the original bug won't be valid any more) So please stick to one system if possible. You could for example just introduce a new state "UserBug" in the workflow which comes just before "Dispatched". Regards, Volker > Thanks, > iris From kelly.ohair at oracle.com Thu Dec 15 17:27:44 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Dec 2011 09:27:44 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EE99E09.3030904@oracle.com> References: <4EE99E09.3030904@oracle.com> Message-ID: <3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> On Dec 14, 2011, at 11:13 PM, David Holmes wrote: >> >> The source for the information you really want about whether a fix has been >> applied should come from the source control system, not the bug system. >> That's the only information you can really trust. > > I'm not aware of any way to run queries against mercurial the way we can with BQ and will be able to with Jira. I echo Joe's sentiment that having both resolved and unresolved issues be "closed" makes it harder to find those resolved issues. Doing bug triage is aided immensely if you can query which bugs were fixed in a specific build of a specific release. This page is generated from the Mercurial repositories: http://download.java.net/jdk7u4/changes/jdk7u4-b03.html The script, or a variation of it for openjdk6, is at http://hg.openjdk.java.net/jdk6/jdk6/file/tip/make/scripts/jdkreport.pl So I do think it is possible to query the repositories for what bugs were fixed. -kto From xiomara.jayasena at oracle.com Thu Dec 15 18:01:13 2011 From: xiomara.jayasena at oracle.com (Xiomara Jayasena) Date: Thu, 15 Dec 2011 10:01:13 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> References: <4EE80C48.7060406@oracle.com> <4EE99E09.3030904@oracle.com 3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> Message-ID: <993e7be9-3c95-455d-84c0-46c961576a65@default> > > > This page is generated from the Mercurial repositories: > http://download.java.net/jdk7u4/changes/jdk7u4-b03.html > The script, or a variation of it for openjdk6, is at > http://hg.openjdk.java.net/jdk6/jdk6/file/tip/make/scripts/jdkreport.pl > > So I do think it is possible to query the repositories for what bugs > were fixed. This is true, but for now though those results are only as good as what the users (developer or integrator) put into the comments when integrating. The script above originally written for JDK 7 gets the bug IDs from the comments put in by devs/integrators. -Xiomara > > -kto > From kelly.ohair at oracle.com Thu Dec 15 22:20:26 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Dec 2011 14:20:26 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <993e7be9-3c95-455d-84c0-46c961576a65@default> References: <4EE80C48.7060406@oracle.com> <4EE99E09.3030904@oracle.com 3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> <993e7be9-3c95-455d-84c0-46c961576a65@default> Message-ID: <3DFDFF9B-9EB7-463D-8252-441A6CC7696E@oracle.com> On Dec 15, 2011, at 10:01 AM, Xiomara Jayasena wrote: > > >> >> >> This page is generated from the Mercurial repositories: >> http://download.java.net/jdk7u4/changes/jdk7u4-b03.html >> The script, or a variation of it for openjdk6, is at >> http://hg.openjdk.java.net/jdk6/jdk6/file/tip/make/scripts/jdkreport.pl >> >> So I do think it is possible to query the repositories for what bugs >> were fixed. > > This is true, but for now though those results are only as good as what the users (developer or integrator) put into the comments when integrating. The script above originally written for JDK 7 gets the bug IDs from the comments put in by devs/integrators. But I have historically trusted the developer changeset comments over the state of the bug tracking system. There have been very few cases (< 1%) where the changeset comments have had the wrong bug number. The bug tracking system sometimes lags behind the actual change being integrated. If in the future we can do better at making both more accurate. -kto From georges.saab at oracle.com Fri Dec 16 01:01:03 2011 From: georges.saab at oracle.com (Georges Saab) Date: Thu, 15 Dec 2011 17:01:03 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> Hi Volker -- Please see inline... On 15 dec 2011, at 05:45, Volker Simonis wrote: > Hi Iris, [SNIP] > > I personally don't think that two parallel JIRA instances will be > particularly useful. They will be just a constant cause of confusion. > Because eventually you'd have to transfer bugs from the "end-user" bug > system to the "real" bug system. And even if you'd somehow manage to > keep the bug ids unique between the two systems, you would still have > two systems with all the drawbacks: > - which system to search (before entering a new bug) > - in which system to track the bug > - you'll have to keep the bug content in sync between the two systems > (otherwise, if you just move the bug from one system to the other, > links to the original bug won't be valid any more) > > So please stick to one system if possible. You could for example just > introduce a new state "UserBug" in the workflow which comes just > before "Dispatched". Currently there is a system (web-bugs) for handling bug reports from end users. Most of these are not developers. Most have no idea what information is needed to track down an issue. There are millions of these reports that come in each year. Many need more info. Many are duplicates. Many are not even bugs. Every once in a while something really really important comes through this channel, however. IMHO - we want end users to be able to file reports, but keep them separate from the database used by development. We want the OpenJDK community to be able to help triage and respond so that it is possible to scale the way we deal with these and not miss real and important reports -- but get these swiftly and smoothly transitioned to the development JIRA project. > > Regards, > Volker > > >> Thanks, >> iris From david.holmes at oracle.com Fri Dec 16 05:00:03 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Dec 2011 15:00:03 +1000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> References: <4EE99E09.3030904@oracle.com> <3EEBB034-57BB-4E68-8F5B-533392AD0852@oracle.com> Message-ID: <4EEAD053.7000208@oracle.com> On 16/12/2011 3:27 AM, Kelly O'Hair wrote: > > On Dec 14, 2011, at 11:13 PM, David Holmes wrote: > >>> >>> The source for the information you really want about whether a fix >>> has been >>> applied should come from the source control system, not the bug system. >>> That's the only information you can really trust. >> >> I'm not aware of any way to run queries against mercurial the way we >> can with BQ and will be able to with Jira. I echo Joe's sentiment that >> having both resolved and unresolved issues be "closed" makes it harder >> to find those resolved issues. Doing bug triage is aided immensely if >> you can query which bugs were fixed in a specific build of a specific >> release. > > > This page is generated from the Mercurial repositories: > http://download.java.net/jdk7u4/changes/jdk7u4-b03.html > The script, or a variation of it for openjdk6, is at > http://hg.openjdk.java.net/jdk6/jdk6/file/tip/make/scripts/jdkreport.pl > > So I do think it is possible to query the repositories for what bugs > were fixed. Okay - yes you can post-process "hg log" output, but unless there is a nice GUI front-end for this I don't think it is viable as a replacement for the reporting functionality provided by BQ or JIRA. So to return to the original point I still think that the bug workflow should aid such queries by distinguishing between closed-resolved and closed-not-resolved. There's no reason for the bug database to lag the repository metadata if we can add the right hooks so that pushes update the bug report. Cheers, David > > -kto > From joe.darcy at oracle.com Fri Dec 16 05:33:31 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 15 Dec 2011 21:33:31 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EEAD82B.9010703@oracle.com> On 12/14/2011 12:01 PM, Iris Clark wrote: [snip] >> Though where it says; >> >> "Sufficient investigation has been preformed to gain a basic understanding >> of how this bug/feature request should be addressed. There is no requirement >> that an actual solution be known at this time." >> >> this matches more with "Cause known" than "Fix Understood". > The definition I provided does not adequately describe what one should expect > for this status; hence my question immediately after that line: > > "The definition of this status should match the current > definition/expectation for "Fix Understood". What is that definition? > > Is it sufficient to remove the final sentence? Perhaps it should be replaced > with a recommended confidence level? > > "Sufficient investigation has been preformed to gain a basic understanding > of how this bug/feature request should be addressed and the associated risks." > >> I really like what we currently have in terms of: >> - cause known (problem has been identified) >> - fix understood (a solution seems to have been devised) >> - fix in progress (actively implementing the solution) >> >> As an IE (and someone who watches many new bug reports) I will often take a >> bug to "cause known" as part of my initial eval. Combining an understanding >> of the problem with the discovery of a solution into one state loses very >> important information in my opinion. For example, a bug with an understood >> fix can be easily picked up by a new developer as a "starter" bug. > I agree that when we remove statuses, information may be lost. > > I had combined these two statuses because my impression was that they were not > currently being used effectively. What seems to happen in many cases is that > once sufficient investigation has been done to identify the cause, the > recommendation for a solution would be known as well). > > What experience do other people have with these statuses? Looking over the 100+ open bugs where I'm the responsible engineer, I have about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood. Should these three related conditions about an increasing understanding of the bug be covered in one state with three substates? >> I don't think "closed: future project" works very well. Once a bug is >> closed it should remain closed in my view. Maybe a new substatus of >> "accepted" could be "future project" to indicate deferral? I believe the intention of "closed: future project" state is intended to more neatly address issues like a "Java should have a module system" bug, filed back in 1996. Leaving these is a chronic accepted or cause known state for years obscures other issues. -Joe From iris.clark at oracle.com Fri Dec 16 19:07:59 2011 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 16 Dec 2011 11:07:59 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EEAD82B.9010703@oracle.com> References: Message-ID: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> Hi! > >> I really like what we currently have in terms of: > >> - cause known (problem has been identified) > >> - fix understood (a solution seems to have been devised) > >> - fix in progress (actively implementing the solution) > >> > >> As an IE (and someone who watches many new bug reports) I will often > >> take a bug to "cause known" as part of my initial eval. Combining an > >> understanding of the problem with the discovery of a solution into > >> one state loses very important information in my opinion. For > >> example, a bug with an understood fix can be easily picked up by a new > >> developer as a "starter" bug. I agree that when we remove statuses, > >> information may be lost. > > > > I had combined these two statuses because my impression was that they > > were not currently being used effectively. What seems to happen in > > many cases is that once sufficient investigation has been done to > > identify the cause, the recommendation for a solution would be known as > > well). > > > > What experience do other people have with these statuses? > > Looking over the 100+ open bugs where I'm the responsible engineer, I have > about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood. > > Should these three related conditions about an increasing understanding of the > bug be covered in one state with three substates? It's a possibility. I want to step back to think about what exactly we need to represent. Let's start by think about what the various points of a bug's life are and the points are of interest (and to who). Here's my basic understanding of what happens to a bug from the time it come in (i.e. currently "Dispatched") to the time somebody is actively working on it (i.e. "Fix in Progress"). Assume adjustments to bug content as appropriate for every step. 1. Dispatched: A bug comes in. 2. Accepted*: Component teams do initial triage. The goal is to verify that there's sufficient information to investigate the bug and determine importance of the reported problem assuming it is real. An initial Priority, Cat/Subcat, and target release are verified/assigned as appropriate. NOTE: There is no guarantee that the problem actually exists! 3. The reported problem reproduced. Priority, target release, etc. may be adjusted. 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to gain a basic understanding of how the problem should be addressed. Evaluation updated. 5. BT Fix Understood/JIRA Understood: A potential solution is devised. Impact and risks associated with the solution are known. Suggested fix updated. 6. Fix in Progress: Active work started to address the problem. Did I miss anything? [ Note that 3 does not have a name in either the proposed JIRA workflow or BT. Minimally, that needs to be addressed. ] 3-5 feel like they're very tightly related so are perhaps a single status with sequenced substatuses? (I don't know if JIRA supports the concept of "sequenced substatuses", so these might need to be individual statuses.) [ We'll need to visit the names after we decide what they should represent. ] > >> I don't think "closed: future project" works very well. Once a bug is > >> closed it should remain closed in my view. Maybe a new substatus of > >> "accepted" could be "future project" to indicate deferral? > > I believe the intention of "closed: future project" state is intended to more > neatly address issues like a "Java should have a module system" bug, filed > back in 1996. Leaving these is a chronic accepted or cause known state for > years obscures other issues Does it feel like we have a lot of these kinds of bugs? Would it make it easier to close these and similar bugs if "Closed: Future Project" exists? Thanks, iris From richard.bair at oracle.com Fri Dec 16 19:32:23 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 16 Dec 2011 11:32:23 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> References: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> Message-ID: <9B340066-69CF-457E-BBAC-A489F35A12D9@oracle.com> >>> What experience do other people have with these statuses? >> >> Looking over the 100+ open bugs where I'm the responsible engineer, I have >> about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood. >> >> Should these three related conditions about an increasing understanding of the >> bug be covered in one state with three substates? Personally I've never had a use for those various substates. To me it is just a bother and, if the system had such states, I'd probably not use them. The bug would go from "accept" to "fixed" and skip the others. Richard From joe.darcy at oracle.com Fri Dec 16 19:44:08 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 16 Dec 2011 11:44:08 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> References: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> Message-ID: <4EEB9F88.707@oracle.com> On 12/16/2011 11:07 AM, Iris Clark wrote: > Hi! > >>>> I really like what we currently have in terms of: >>>> - cause known (problem has been identified) >>>> - fix understood (a solution seems to have been devised) >>>> - fix in progress (actively implementing the solution) >>>> >>>> As an IE (and someone who watches many new bug reports) I will often >>>> take a bug to "cause known" as part of my initial eval. Combining an >>>> understanding of the problem with the discovery of a solution into >>>> one state loses very important information in my opinion. For >>>> example, a bug with an understood fix can be easily picked up by a new >>>> developer as a "starter" bug. I agree that when we remove statuses, >>>> information may be lost. >>> I had combined these two statuses because my impression was that they >>> were not currently being used effectively. What seems to happen in >>> many cases is that once sufficient investigation has been done to >>> identify the cause, the recommendation for a solution would be known as >>> well). >>> >>> What experience do other people have with these statuses? >> Looking over the 100+ open bugs where I'm the responsible engineer, I have >> about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood. >> >> Should these three related conditions about an increasing understanding of the >> bug be covered in one state with three substates? > It's a possibility. I want to step back to think about what exactly we need > to represent. Let's start by think about what the various points of a bug's > life are and the points are of interest (and to who). Here's my basic > understanding of what happens to a bug from the time it come in > (i.e. currently "Dispatched") to the time somebody is actively working on it > (i.e. "Fix in Progress"). > > Assume adjustments to bug content as appropriate for every step. > > 1. Dispatched: A bug comes in. > 2. Accepted*: Component teams do initial triage. The goal is to verify that > there's sufficient information to investigate the bug and determine > importance of the reported problem assuming it is real. An initial > Priority, Cat/Subcat, and target release are verified/assigned as > appropriate. > NOTE: There is no guarantee that the problem actually exists! > 3. The reported problem reproduced. Priority, target release, etc. may be > adjusted. > 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to > gain a basic understanding of how the problem should be addressed. > Evaluation updated. > 5. BT Fix Understood/JIRA Understood: A potential solution is devised. > Impact and risks associated with the solution are known. Suggested fix > updated. > 6. Fix in Progress: Active work started to address the problem. > > Did I miss anything? [ Note that 3 does not have a name in either the > proposed JIRA workflow or BT. Minimally, that needs to be addressed. ] I don't know is the reproduction or non-reproduction needs to be captured formally in the database model as opposed to in comments. Is there interest in generating statistics like, what percentage of incoming bugs cannot be reproduced? > 3-5 feel like they're very tightly related so are perhaps a single status with > sequenced substatuses? (I don't know if JIRA supports the concept of "sequenced > substatuses", so these might need to be individual statuses.) > > [ We'll need to visit the names after we decide what they should represent. ] I suggest categorize the main-line states with indented substates as Dispatched Investigating accepted cause known fix understood Fix(ing) in progress Fixed Resolved Verified Unverified >>>> I don't think "closed: future project" works very well. Once a bug is >>>> closed it should remain closed in my view. Maybe a new substatus of >>>> "accepted" could be "future project" to indicate deferral? >> I believe the intention of "closed: future project" state is intended to more >> neatly address issues like a "Java should have a module system" bug, filed >> back in 1996. Leaving these is a chronic accepted or cause known state for >> years obscures other issues > Does it feel like we have a lot of these kinds of bugs? Would it make it > easier to close these and similar bugs if "Closed: Future Project" exists? > Some areas do have a large percentage of such bugs, for example Java language features. -Joe From iris.clark at oracle.com Fri Dec 16 19:53:04 2011 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 16 Dec 2011 11:53:04 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> References: Message-ID: Hi! > > I personally don't think that two parallel JIRA instances will be > > particularly useful. They will be just a constant cause of confusion. > > Because eventually you'd have to transfer bugs from the "end-user" bug > > system to the "real" bug system. And even if you'd somehow manage to > > keep the bug ids unique between the two systems, you would still have > > two systems with all the drawbacks: > > - which system to search (before entering a new bug) > > - in which system to track the bug > > - you'll have to keep the bug content in sync between the two systems > > (otherwise, if you just move the bug from one system to the other, > > links to the original bug won't be valid any more) > > > > So please stick to one system if possible. You could for example just > > introduce a new state "UserBug" in the workflow which comes just > > before "Dispatched". > > Currently there is a system (web-bugs) for handling bug reports from end > users. Most of these are not developers. Most have no idea what information > is needed to track down an issue. There are millions of these reports that > come in each year. Many need more info. Many are duplicates. Many are not > even bugs. > > Every once in a while something really really important comes through this > channel, however. > > IMHO - we want end users to be able to file reports, but keep them separate > from the database used by development. We want the OpenJDK community to be > able to help triage and respond so that it is possible to scale the way we > deal with these and not miss real and important reports -- but get these > swiftly and smoothly transitioned to the development JIRA project. While I understand the desire to have a single JIRA Project for all bugs regardless of their source, I'm not confident that that is very feasible given the nature of typical end-user-submitted bugs. Even with the hints we provide during submission (i.e. explicit request for "Steps to reproduce", "Expected Result", "Actual Result", etc.), we still get problematic reports as Georges indicates above. I don't think that one or two statuses tacked on to the beginning of the Developer workflow will be sufficient. I'm also concerned that by having all of these end-user bugs within the same JIRA Project, we'll introduce a degradation in our ability to manage the main developer workload. Thanks, iris From brian.beck at oracle.com Fri Dec 16 22:17:07 2011 From: brian.beck at oracle.com (Brian Beck) Date: Fri, 16 Dec 2011 14:17:07 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> References: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> Message-ID: <4EEBC363.4090608@oracle.com> On 12/16/11 11:07 AM, Iris Clark wrote: > [snip] > 1. Dispatched: A bug comes in. > 2. Accepted*: Component teams do initial triage. The goal is to verify that > there's sufficient information to investigate the bug and determine > importance of the reported problem assuming it is real. An initial > Priority, Cat/Subcat, and target release are verified/assigned as > appropriate. > NOTE: There is no guarantee that the problem actually exists! > 3. The reported problem reproduced. Priority, target release, etc. may be > adjusted. > 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to > gain a basic understanding of how the problem should be addressed. > Evaluation updated. > 5. BT Fix Understood/JIRA Understood: A potential solution is devised. > Impact and risks associated with the solution are known. Suggested fix > updated. > 6. Fix in Progress: Active work started to address the problem. > > Did I miss anything? [ Note that 3 does not have a name in either the > proposed JIRA workflow or BT. Minimally, that needs to be addressed. ] > > 3-5 feel like they're very tightly related so are perhaps a single status with > sequenced substatuses? (I don't know if JIRA supports the concept of "sequenced > substatuses", so these might need to be individual statuses.) > To me 3-5 are very waterfall-esque. In particular, 4 and 5 are sort of theoretical states. Very often they don't exist as discreet points of time. For many bugs I can't say I understand the problem until I know the fix. Likewise I can't say I understand the fix until I've made it and tested it. There may be some element of personal style in this. I have met engineers who rigorously take bugs through all these states in Bugster. But I know this doesn't suit me. I also know from my days on the Bug Police that it doesn't suit lots of others. From a project management point of view the states that need to be distinguished are: 1. Open (a.k.a. accepted, a.k.a. triaged) - a valid bug that's waiting to be worked on 2. In Progress - an issue that is currently being worked on 3. Resolved - an issue that is solved These conditions need to be tracked widely across all types of issues and all types of work styles. When it comes to how much is known about an individual bug, this is best left to the description and commentary. They are far better at recording the nuances that are necessary to resolve a particular issue. Brian. From iris.clark at oracle.com Fri Dec 16 22:45:04 2011 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 16 Dec 2011 14:45:04 -0800 (PST) Subject: FW: OpenJDK bug database: DRAFT Developer Workflow Message-ID: John said his message bounced. Attempting to forward. iris From: John Pampuch Sent: Friday, December 16, 2011 2:20 PM To: discuss at openjdk.java.net Subject: Re: OpenJDK bug database: DRAFT Developer Workflow Iris- One concern I have in the "Accepted" state that you describe below is that it may set expectations with someone who is paying attention to the bug. On many bugs, the target release can't really be determined until we understand the bug better. If we could, I'd prefer requiring setting the target release until step 4. -John On 12/16/11 11:07 AM, Iris Clark wrote: Hi! I really like what we currently have in terms of: - cause known (problem has been identified) - fix understood (a solution seems to have been devised) - fix in progress (actively implementing the solution) As an IE (and someone who watches many new bug reports) I will often take a bug to "cause known" as part of my initial eval. Combining an understanding of the problem with the discovery of a solution into one state loses very important information in my opinion. For example, a bug with an understood fix can be easily picked up by a new developer as a "starter" bug. I agree that when we remove statuses, information may be lost. I had combined these two statuses because my impression was that they were not currently being used effectively. What seems to happen in many cases is that once sufficient investigation has been done to identify the cause, the recommendation for a solution would be known as well). What experience do other people have with these statuses? Looking over the 100+ open bugs where I'm the responsible engineer, I have about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood. Should these three related conditions about an increasing understanding of the bug be covered in one state with three substates? It's a possibility. I want to step back to think about what exactly we need to represent. Let's start by think about what the various points of a bug's life are and the points are of interest (and to who). Here's my basic understanding of what happens to a bug from the time it come in (i.e. currently "Dispatched") to the time somebody is actively working on it (i.e. "Fix in Progress"). Assume adjustments to bug content as appropriate for every step. 1. Dispatched: A bug comes in. 2. Accepted*: Component teams do initial triage. The goal is to verify that there's sufficient information to investigate the bug and determine importance of the reported problem assuming it is real. An initial Priority, Cat/Subcat, and target release are verified/assigned as appropriate. NOTE: There is no guarantee that the problem actually exists! 3. The reported problem reproduced. Priority, target release, etc. may be adjusted. 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to gain a basic understanding of how the problem should be addressed. Evaluation updated. 5. BT Fix Understood/JIRA Understood: A potential solution is devised. Impact and risks associated with the solution are known. Suggested fix updated. 6. Fix in Progress: Active work started to address the problem. Did I miss anything? [ Note that 3 does not have a name in either the proposed JIRA workflow or BT. Minimally, that needs to be addressed. ] 3-5 feel like they're very tightly related so are perhaps a single status with sequenced substatuses? (I don't know if JIRA supports the concept of "sequenced substatuses", so these might need to be individual statuses.) [ We'll need to visit the names after we decide what they should represent. ] I don't think "closed: future project" works very well. Once a bug is closed it should remain closed in my view. Maybe a new substatus of "accepted" could be "future project" to indicate deferral? I believe the intention of "closed: future project" state is intended to more neatly address issues like a "Java should have a module system" bug, filed back in 1996. Leaving these is a chronic accepted or cause known state for years obscures other issues Does it feel like we have a lot of these kinds of bugs? Would it make it easier to close these and similar bugs if "Closed: Future Project" exists? Thanks, iris --------------050600050202000504050809-- From volker.simonis at gmail.com Sat Dec 17 00:18:59 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 17 Dec 2011 01:18:59 +0100 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> Message-ID: Hi Iris, Georges, OK, I see the problem with "end user" bugs if these are really "millions" per year. But than please seriously consider giving any OpenJDK Participant (anybody who subscribed to an OpenJDK mailing list) or at least any OpenJDK Contributor (Participants who have signed the OCA) the right to directly submit bugs into the "real" bug system. I don't think that there will be millions of these people (the current list of Oracle Contributor Agreement signatories at http://www.oracle.com/technetwork/community/oca-486395.html currently lists ~1400 signatories) and I don't suppose they will submit more than some hundreds or perhaps thousands of bugs. On the other hand if somebody signed the OCA I think this is a strong indication that he seriously wants to contribute to the OpenJDK and I think most of the reports from these people will be high quality bug reports. There's nothing more annoying for a developer who has identified and fixed a bug in the OpenJDK than first going trough the process of asking sombody at Oracle to please open a "real" bug report for the issue before he can actually file an "official" request for review with a valid bug ID. Regards, Volker On Fri, Dec 16, 2011 at 8:53 PM, Iris Clark wrote: > Hi! > >> > I personally don't think that two parallel JIRA instances will be >> > particularly useful. They will be just a constant cause of confusion. >> > Because eventually you'd have to transfer bugs from the "end-user" bug >> > system to the "real" bug system. And even if you'd somehow manage to >> > keep the bug ids unique between the two systems, you would still have >> > two systems with all the drawbacks: >> > - which system to search (before entering a new bug) >> > - in which system to track the bug >> > - you'll have to keep the bug content in sync between the two systems >> > (otherwise, if you just move the bug from one system to the other, >> > links to the original bug won't be valid any more) >> > >> > So please stick to one system if possible. You could for example just >> > introduce a new state "UserBug" in the workflow which comes just >> > before "Dispatched". >> >> Currently there is a system (web-bugs) for handling bug reports from end >> users. ?Most of these are not developers. ?Most have no idea what information >> is needed to track down an issue. ?There are millions of these reports that >> come in each year. ?Many need more info. Many are duplicates. ?Many are not >> even bugs. >> >> Every once in a while something really really important comes through this >> channel, however. >> >> IMHO - we want end users to be able to file reports, but keep them separate >> from the database used by development. ?We want the OpenJDK community to be >> able to help triage and respond so that it is possible to scale the way we >> deal with these and not miss real and important reports -- but get these >> swiftly and smoothly transitioned to the development JIRA project. > > While I understand the desire to have a single JIRA Project for all bugs > regardless of their source, I'm not confident that that is very feasible given > the nature of typical end-user-submitted bugs. ?Even with the hints we > provide during submission (i.e. explicit request for "Steps to reproduce", > "Expected Result", "Actual Result", etc.), we still get problematic reports > as Georges indicates above. > > I don't think that one or two statuses tacked on to the beginning of the > Developer workflow will be sufficient. ?I'm also concerned that by having all > of these end-user bugs within the same JIRA Project, we'll introduce a > degradation in our ability to manage the main developer workload. > > Thanks, > iris From david.holmes at oracle.com Sat Dec 17 09:24:25 2011 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Dec 2011 19:24:25 +1000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EEBC363.4090608@oracle.com> References: <55bc65a2-f414-4e80-b451-1c916e4d630b@default> <4EEBC363.4090608@oracle.com> Message-ID: <4EEC5FC9.4050601@oracle.com> On 17/12/2011 8:17 AM, Brian Beck wrote: > On 12/16/11 11:07 AM, Iris Clark wrote: >> [snip] >> 1. Dispatched: A bug comes in. >> 2. Accepted*: Component teams do initial triage. The goal is to verify >> that >> there's sufficient information to investigate the bug and determine >> importance of the reported problem assuming it is real. An initial >> Priority, Cat/Subcat, and target release are verified/assigned as >> appropriate. >> NOTE: There is no guarantee that the problem actually exists! >> 3. The reported problem reproduced. Priority, target release, etc. may be >> adjusted. >> 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to >> gain a basic understanding of how the problem should be addressed. >> Evaluation updated. >> 5. BT Fix Understood/JIRA Understood: A potential solution is devised. >> Impact and risks associated with the solution are known. Suggested fix >> updated. >> 6. Fix in Progress: Active work started to address the problem. >> >> Did I miss anything? [ Note that 3 does not have a name in either the >> proposed JIRA workflow or BT. Minimally, that needs to be addressed. ] >> >> 3-5 feel like they're very tightly related so are perhaps a single >> status with >> sequenced substatuses? (I don't know if JIRA supports the concept of >> "sequenced >> substatuses", so these might need to be individual statuses.) >> > To me 3-5 are very waterfall-esque. In particular, 4 and 5 are sort of > theoretical states. Very often they don't exist as discreet points of > time. For many bugs I can't say I understand the problem until I know > the fix. Likewise I can't say I understand the fix until I've made it > and tested it. > > There may be some element of personal style in this. I have met > engineers who rigorously take bugs through all these states in Bugster. > But I know this doesn't suit me. I also know from my days on the Bug > Police that it doesn't suit lots of others. Not just personal style but also what products you work with and their release schedules and resourcing etc, and what role you are playing with the bug. For the products that I've worked on these sub-states were used extensively. Getting a problem to "cause known" meant you now know how the problems arises, under what conditions it might also arise and the potential impact it has. This may lead to a prioritising of the bug so that a fix is found immediately, or it may mean this problem is not critical and can be left to a later time (likely another release) - leaving it in "cause known". You may be working on a solution to a problem and time is running out to get this solution in place. Again the bug may be deemed not critical for this release and deferred, so you can mark it as "fix understood" and move on to critical work. Sometimes an apparent fix is "obvious" but you (as the initial evaluator) are not the one who will fix this, nor even the one who may assign a resource to fix it, so again it can be marked as "fix understood" (with comments as to what the suggested fix is). > From a project management point of view the states that need to be > distinguished are: > > 1. Open (a.k.a. accepted, a.k.a. triaged) - a valid bug that's waiting > to be worked on > 2. In Progress - an issue that is currently being worked on > 3. Resolved - an issue that is solved This is insufficient in my opinion as you have no idea to what extent progress is being made. If the weekly bug stats show X bugs as "cause known" and Y as "fix understood" then you have a much better idea as to what time and resources are likely to be needed to take them to "fix available" compared to just seeing "X+Y" in progress bugs. David ----- > These conditions need to be tracked widely across all types of issues > and all types of work styles. When it comes to how much is known about > an individual bug, this is best left to the description and commentary. > They are far better at recording the nuances that are necessary to > resolve a particular issue. > > Brian. > > > > From georges.saab at oracle.com Sun Dec 18 07:18:38 2011 From: georges.saab at oracle.com (Georges Saab) Date: Sat, 17 Dec 2011 23:18:38 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> Message-ID: <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> Hi Volker -- Please see inline On 16 dec 2011, at 16:18, Volker Simonis wrote: > Hi Iris, Georges, > > OK, I see the problem with "end user" bugs if these are really > "millions" per year. > > But than please seriously consider giving any OpenJDK Participant > (anybody who subscribed to an OpenJDK mailing list) or at least any > OpenJDK Contributor (Participants who have signed the OCA) the right > to directly submit bugs into the "real" bug system. I don't think that > there will be millions of these people (the current list of Oracle > Contributor Agreement signatories at > http://www.oracle.com/technetwork/community/oca-486395.html currently > lists ~1400 signatories) and I don't suppose they will submit more > than some hundreds or perhaps thousands of bugs. On the other hand if > somebody signed the OCA I think this is a strong indication that he > seriously wants to contribute to the OpenJDK and I think most of the > reports from these people will be high quality bug reports. Nothing to 'consider', for me it is a requirement that the new system allow more of the OpenJDK community than just those employed by Oracle to create a bug! > > There's nothing more annoying for a developer who has identified and > fixed a bug in the OpenJDK than first going trough the process of > asking sombody at Oracle to please open a "real" bug report for the > issue before he can actually file an "official" request for review > with a valid bug ID. > And by the same token, for somebody at Oracle to spend time opening a bug report so someone else can check in their fix (not to mention having to do checking testing for them and in some cases make fixes to the fixes) is if not annoying, certainly not exciting, especially when they have a long list of bugs they need to be working on themselves! > Regards, > Volker > > > On Fri, Dec 16, 2011 at 8:53 PM, Iris Clark wrote: >> Hi! >> >>>> I personally don't think that two parallel JIRA instances will be >>>> particularly useful. They will be just a constant cause of confusion. >>>> Because eventually you'd have to transfer bugs from the "end-user" bug >>>> system to the "real" bug system. And even if you'd somehow manage to >>>> keep the bug ids unique between the two systems, you would still have >>>> two systems with all the drawbacks: >>>> - which system to search (before entering a new bug) >>>> - in which system to track the bug >>>> - you'll have to keep the bug content in sync between the two systems >>>> (otherwise, if you just move the bug from one system to the other, >>>> links to the original bug won't be valid any more) >>>> >>>> So please stick to one system if possible. You could for example just >>>> introduce a new state "UserBug" in the workflow which comes just >>>> before "Dispatched". >>> >>> Currently there is a system (web-bugs) for handling bug reports from end >>> users. Most of these are not developers. Most have no idea what information >>> is needed to track down an issue. There are millions of these reports that >>> come in each year. Many need more info. Many are duplicates. Many are not >>> even bugs. >>> >>> Every once in a while something really really important comes through this >>> channel, however. >>> >>> IMHO - we want end users to be able to file reports, but keep them separate >>> from the database used by development. We want the OpenJDK community to be >>> able to help triage and respond so that it is possible to scale the way we >>> deal with these and not miss real and important reports -- but get these >>> swiftly and smoothly transitioned to the development JIRA project. >> >> While I understand the desire to have a single JIRA Project for all bugs >> regardless of their source, I'm not confident that that is very feasible given >> the nature of typical end-user-submitted bugs. Even with the hints we >> provide during submission (i.e. explicit request for "Steps to reproduce", >> "Expected Result", "Actual Result", etc.), we still get problematic reports >> as Georges indicates above. >> >> I don't think that one or two statuses tacked on to the beginning of the >> Developer workflow will be sufficient. I'm also concerned that by having all >> of these end-user bugs within the same JIRA Project, we'll introduce a >> degradation in our ability to manage the main developer workload. >> >> Thanks, >> iris From georges.saab at oracle.com Sun Dec 18 07:25:35 2011 From: georges.saab at oracle.com (Georges Saab) Date: Sat, 17 Dec 2011 23:25:35 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <0A578E3F-B5E3-494D-A3E2-BEFE4DADC240@oracle.com> Please see inline On 16 dec 2011, at 14:45, Iris Clark wrote: [snip] > > From: John Pampuch > Sent: Friday, December 16, 2011 2:20 PM > To: discuss at openjdk.java.net > Subject: Re: OpenJDK bug database: DRAFT Developer Workflow > > > > Iris- > > One concern I have in the "Accepted" state that you describe below is that it may set expectations with someone who is paying attention to the bug. On many bugs, the target release can't really be determined until we understand the bug better. If we could, I'd prefer requiring setting the target release until step 4. > > -John > [snip] Two comments on this: 1. I personally like the terms 'unconfirmed' and 'confirmed' rather than 'accepted' in part to be clearer about expectations. 2. IMHO targeting should not be viewed as a commitment TO FIX in a specific release, rather a commitment TO WORK on the bug in the context of the release. For instance, a bug which appears to be very important if it really exists might be immediately targeted to the current update release, meaning -- we need to work on this in the context of this release until we know that it is not a bug or not as important a bug as it sounds now, in which case it could be retargeted to a later release. From martijnverburg at gmail.com Mon Dec 19 11:40:36 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Dec 2011 11:40:36 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> Message-ID: Hi all, Please see inline > On 16 dec 2011, at 16:18, Volker Simonis wrote: > >> Hi Iris, Georges, >> >> OK, I see the problem with "end user" bugs if these are really >> "millions" per year. Just on this, what are the real numbers we are talking about here? I run one JIRA instance which holds ~10 projects (a team/feature split) and an annoyance is the lack of ability to transfer issues between projects, it would be a manual step (as JIRA currently stands). It might be easier to have them in one project but use Component or a Status to filter out end user reports. People's Dashboards and default reports can easily omit these so that they can remain focussed on their tasks or a 'confirmed/trusted' set of issues. Cheers, Martijn From Alan.Bateman at oracle.com Mon Dec 19 12:55:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Dec 2011 12:55:08 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> Message-ID: <4EEF342C.9000103@oracle.com> On 19/12/2011 11:40, Martijn Verburg wrote: > : > Just on this, what are the real numbers we are talking about here? I remember Roger Lewis provided some data on this. I found one mail [1] where he said 450/month. There is clearly potential to crowdsource these incidents but would need some way to move real bug reports to the right place. -Alan. [1] http://mail.openjdk.java.net/pipermail/discuss/2011-June/001913.html From martijnverburg at gmail.com Mon Dec 19 13:38:59 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Dec 2011 13:38:59 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EEF342C.9000103@oracle.com> References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> <4EEF342C.9000103@oracle.com> Message-ID: Hi Alan/All, >> Just on this, what are the real numbers we are talking about here? > > I remember Roger Lewis provided some data on this. I found one mail [1] > where he said 450/month. There is clearly potential to crowdsource these > incidents but would need some way to move real bug reports to the right > place. OK, it's not as bad as I feared, but nor is it a number that can just be left unmanaged. I think this is a case where the wider OpenJDK community and the JUG membership could act as a crowd sourced triage. This would hopefully let the OpenJDK comitters focus on the confirmed issues. Thoughts? Martijn From iris.clark at oracle.com Mon Dec 19 16:22:26 2011 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 19 Dec 2011 08:22:26 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> <4EEF342C.9000103@oracle.com> Message-ID: <2d902009-6612-4a37-92c1-0f96e69d9378@default> Hi, Martijn. In my mind, this would be ideal. iris -----Original Message----- From: Martijn Verburg [mailto:martijnverburg at gmail.com] Sent: Monday, December 19, 2011 5:39 AM To: Alan Bateman Cc: discuss at openjdk.java.net Subject: Re: OpenJDK bug database: DRAFT Developer Workflow Hi Alan/All, >> Just on this, what are the real numbers we are talking about here? > > I remember Roger Lewis provided some data on this. I found one mail > [1] where he said 450/month. There is clearly potential to crowdsource > these incidents but would need some way to move real bug reports to > the right place. OK, it's not as bad as I feared, but nor is it a number that can just be left unmanaged. I think this is a case where the wider OpenJDK community and the JUG membership could act as a crowd sourced triage. This would hopefully let the OpenJDK comitters focus on the confirmed issues. Thoughts? Martijn From martijnverburg at gmail.com Mon Dec 19 16:26:49 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Dec 2011 16:26:49 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <2d902009-6612-4a37-92c1-0f96e69d9378@default> References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> <4EEF342C.9000103@oracle.com> <2d902009-6612-4a37-92c1-0f96e69d9378@default> Message-ID: Hi Iris, > In my mind, this would be ideal. I'm planning on having a good community structure in place (it's already forming via the Adopt a JSR, and OpenJDK adoption programs) by the time this JIRA move occurs (mid 2012 I'm guessing?). So perhaps if the initial JIRA workflow design takes this into account? Perhaps an alternative workflow can be thought of in case that initiative fails for whatever reason (but hopefully once a deep roots community forms around this that won't be a problem). Cheers, Martijn > iris > > -----Original Message----- > From: Martijn Verburg [mailto:martijnverburg at gmail.com] > Sent: Monday, December 19, 2011 5:39 AM > To: Alan Bateman > Cc: discuss at openjdk.java.net > Subject: Re: OpenJDK bug database: DRAFT Developer Workflow > > Hi Alan/All, > >>> Just on this, what are the real numbers we are talking about here? >> >> I remember Roger Lewis provided some data on this. I found one mail >> [1] where he said 450/month. There is clearly potential to crowdsource >> these incidents but would need some way to move real bug reports to >> the right place. > > OK, it's not as bad as I feared, but nor is it a number that can just be left unmanaged. I think this is a case where the wider OpenJDK community and the JUG membership could act as a crowd sourced triage. This would hopefully let the OpenJDK comitters focus on the confirmed issues. > > Thoughts? > > Martijn From iris.clark at oracle.com Mon Dec 19 16:51:56 2011 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 19 Dec 2011 08:51:56 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> <4EEF342C.9000103@oracle.com> <2d902009-6612-4a37-92c1-0f96e69d9378@default> Message-ID: <46c8fc01-c4e2-45df-a86d-f40b6cbf1112@default> Hi, Martijn. I'm thrilled to hear that you're thinking of ways for us to engage more of the community! My initial thought was to have a customized workflow for end-user bugs that could take into account the typical interactions that occur for that triage. I don't expect it to be complex, but I could be wrong. I haven't figured out how to define the set of users who can do the triage. OpenJDK Authors doesn't sound quite right, but that's along the right lines, a little bit more commitment than being a Participant and self-nominating with low requirements threshold. I was hoping to get a chance to find out details of how end-user bugs are handled internally before the holidays, but I'm not confident that will happen. (I'll be out beginning on Wed, back the first few days of Jan.) Thanks, iris -----Original Message----- From: Martijn Verburg [mailto:martijnverburg at gmail.com] Sent: Monday, December 19, 2011 8:27 AM To: Iris Clark Cc: Alan Bateman; discuss at openjdk.java.net Subject: Re: OpenJDK bug database: DRAFT Developer Workflow Hi Iris, > In my mind, this would be ideal. I'm planning on having a good community structure in place (it's already forming via the Adopt a JSR, and OpenJDK adoption programs) by the time this JIRA move occurs (mid 2012 I'm guessing?). So perhaps if the initial JIRA workflow design takes this into account? Perhaps an alternative workflow can be thought of in case that initiative fails for whatever reason (but hopefully once a deep roots community forms around this that won't be a problem). Cheers, Martijn > iris > > -----Original Message----- > From: Martijn Verburg [mailto:martijnverburg at gmail.com] > Sent: Monday, December 19, 2011 5:39 AM > To: Alan Bateman > Cc: discuss at openjdk.java.net > Subject: Re: OpenJDK bug database: DRAFT Developer Workflow > > Hi Alan/All, > >>> Just on this, what are the real numbers we are talking about here? >> >> I remember Roger Lewis provided some data on this. I found one mail >> [1] where he said 450/month. There is clearly potential to >> crowdsource these incidents but would need some way to move real bug >> reports to the right place. > > OK, it's not as bad as I feared, but nor is it a number that can just be left unmanaged. I think this is a case where the wider OpenJDK community and the JUG membership could act as a crowd sourced triage. This would hopefully let the OpenJDK comitters focus on the confirmed issues. > > Thoughts? > > Martijn From martijnverburg at gmail.com Mon Dec 19 16:58:46 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Dec 2011 16:58:46 +0000 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <46c8fc01-c4e2-45df-a86d-f40b6cbf1112@default> References: <40CC27E5-AF33-4831-B595-237FD177F47D@oracle.com> <883C9D68-68B7-416C-9D44-BD94D5FD4E67@oracle.com> <4EEF342C.9000103@oracle.com> <2d902009-6612-4a37-92c1-0f96e69d9378@default> <46c8fc01-c4e2-45df-a86d-f40b6cbf1112@default> Message-ID: Hi Iris, That sounds great! Let me know when you're working on that workflow and I'll get a bunch of JUG and OpenJDK enthusiasts together to look it over etc. Cheers, Martijn On 19 December 2011 16:51, Iris Clark wrote: > Hi, Martijn. > > I'm thrilled to hear that you're thinking of ways for us to engage more > of the community! > > My initial thought was to have a customized workflow for end-user bugs > that could take into account the typical interactions that occur for that > triage. ?I don't expect it to be complex, but I could be wrong. I haven't > figured out how to define the set of users who can do the triage. > OpenJDK Authors doesn't sound quite right, but that's along the right > lines, a little bit more commitment than being a Participant and > self-nominating with low requirements threshold. > > I was hoping to get a chance to find out details of how end-user bugs are > handled internally before the holidays, but I'm not confident that will > happen. (I'll be out beginning on Wed, back the first few days of Jan.) > > Thanks, > iris > > -----Original Message----- > From: Martijn Verburg [mailto:martijnverburg at gmail.com] > Sent: Monday, December 19, 2011 8:27 AM > To: Iris Clark > Cc: Alan Bateman; discuss at openjdk.java.net > Subject: Re: OpenJDK bug database: DRAFT Developer Workflow > > Hi Iris, > >> In my mind, this would be ideal. > > I'm planning on having a good community structure in place (it's already forming via the Adopt a JSR, and OpenJDK adoption programs) by the time this JIRA move occurs (mid 2012 I'm guessing?). So perhaps if the initial JIRA workflow design takes this into account? Perhaps an alternative workflow can be thought of in case that initiative fails for whatever reason (but hopefully once a deep roots community forms around this that won't be a problem). > > Cheers, > Martijn > >> iris >> >> -----Original Message----- >> From: Martijn Verburg [mailto:martijnverburg at gmail.com] >> Sent: Monday, December 19, 2011 5:39 AM >> To: Alan Bateman >> Cc: discuss at openjdk.java.net >> Subject: Re: OpenJDK bug database: DRAFT Developer Workflow >> >> Hi Alan/All, >> >>>> Just on this, what are the real numbers we are talking about here? >>> >>> I remember Roger Lewis provided some data on this. I found one mail >>> [1] where he said 450/month. There is clearly potential to >>> crowdsource these incidents but would need some way to move real bug >>> reports to the right place. >> >> OK, it's not as bad as I feared, but nor is it a number that can just be left unmanaged. I think this is a case where the wider OpenJDK community and the JUG membership could act as a crowd sourced triage. This would hopefully let the OpenJDK comitters focus on the confirmed issues. >> >> Thoughts? >> >> Martijn From brian.beck at oracle.com Mon Dec 19 17:30:58 2011 From: brian.beck at oracle.com (Brian Beck) Date: Mon, 19 Dec 2011 09:30:58 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <0A578E3F-B5E3-494D-A3E2-BEFE4DADC240@oracle.com> References: <0A578E3F-B5E3-494D-A3E2-BEFE4DADC240@oracle.com> Message-ID: <4EEF74D2.1070801@oracle.com> On 12/17/11 11:25 PM, Georges Saab wrote: [snip] > 2. IMHO targeting should not be viewed as a commitment TO FIX in a specific release, rather a commitment TO WORK on > the bug in the context of the release. For instance, a bug which appears to be very important if it really exists might be > immediately targeted to the current update release, meaning -- we need to work on this in the context of this release > until we know that it is not a bug or not as important a bug as it sounds now, in which case it could be retargeted to a > later release. Furthermore, IMAHO, targeting should not be considered a *commitment* at all. Targeting is an intention. Re-targeting should not be seen as breaking a commitment but, rather, a normal action given new information about a bug or the world it lives in. Brian. From john.pampuch at oracle.com Tue Dec 20 00:23:15 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Mon, 19 Dec 2011 16:23:15 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EEF74D2.1070801@oracle.com> References: <0A578E3F-B5E3-494D-A3E2-BEFE4DADC240@oracle.com> <4EEF74D2.1070801@oracle.com> Message-ID: <4EEFD573.5040005@oracle.com> So the implication is that the 'targeted' release is a target of analysis, but not necessarily for a fix. I'll bet that isn't the first thought people have when they see that a bug is targeted to a release. I also noticed we've collapsed "Cause Known" and "Fix Understood" into a single state of "Understood". For many bugs, this makes sense, but I'm sure most engineers have also worked on bugs where there is a considerable difference between knowing the cause and knowing the solution. Is there an advantage to removing this additionalstate? Could we have sub-statuses to "Understood" that engineers who choose to use them could? -John On 12/19/11 9:30 AM, Brian Beck wrote: > On 12/17/11 11:25 PM, Georges Saab wrote: > > [snip] >> 2. IMHO targeting should not be viewed as a commitment TO FIX in a >> specific release, rather a commitment TO WORK on >> the bug in the context of the release. For instance, a bug which >> appears to be very important if it really exists might be >> immediately targeted to the current update release, meaning -- we >> need to work on this in the context of this release >> until we know that it is not a bug or not as important a bug as it >> sounds now, in which case it could be retargeted to a >> later release. > Furthermore, IMAHO, targeting should not be considered a *commitment* > at all. Targeting is an intention. Re-targeting should not be seen as > breaking a commitment but, rather, a normal action given new > information about a bug or the world it lives in. > > Brian. From terminatorul at gmail.com Wed Dec 21 14:18:50 2011 From: terminatorul at gmail.com (Timothy Madden) Date: Wed, 21 Dec 2011 16:18:50 +0200 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: <4EE79069.3040707@redhat.com> References: <4EE79069.3040707@redhat.com> Message-ID: On 13.12.2011 19:50, Andrew Haley wrote: > On 12/13/2011 04:21 PM, Timothy Madden wrote: >> Is there no such thing as a local registry/repository/catalog of >> installed java classes/jars, that the launcher could use ? > > This is one of the goals of Project Jigsaw: > > http://openjdk.java.net/projects/jigsaw/ I do believe a monolithic JDK can have disadvantages for non-PC systems, which jigsaw tries to address, but splitting it into modules will automatically lead to module dependencies, module version dependencies, maintained and un-maintained modules, deprecated modules, third-party modules ... and all that daunting stuff, and frankly I am not looking forward to another ".dll hel" within Java ... I find it easier to stick to a monolithic run-time. Putting third-party modules/packages, on the other hand, put into a sort of java system-wide PATH / CLASSPATH / registry, that would make them directly available as soon as they are "installed", would be more appropriate (in other words, java should have modules, but only for user-provided/third-party classes/archives). Which leads to the next question: what is wrong with CLASSPATH ? Why is it recommended that CLASSPATH not be used, and that every java invocation use -cp instead ? Also, using a "known place" for storing the java classes, like the Unix directory hierarchy where each directory (/etc, /usr/local, /usr/bin, /var, /tmp, /opt) is the "known place" for certain files, could also be used as a sort of an "alternative" to (or a first step toward) the system-wide PATH/CLASSPATH/registry method. But it is be more appropriate for .jar files, not necessarily for java class files. I see Linux distributions try to do just that and install .jar files for most packages from the distribution in /usr/share/java. Which makes me think I could also use /usr/local/share/java (or even /opt/share/java, although /opt/share is not specified in the Filesystem Hierarchy Standard) as a default value for CLASSPATH, breaking the recommended usage for CLASSPATH, or in a sh (shell) alias for `java?, which will have about the same effect. But I still think a better/standard way to reference installed java classes would be in order. Thank you, Timothy Madden From terminatorul at gmail.com Wed Dec 21 16:29:09 2011 From: terminatorul at gmail.com (Timothy Madden) Date: Wed, 21 Dec 2011 18:29:09 +0200 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: References: Message-ID: On 14.12.2011 12:00, Fernando Cassia wrote: > On Tue, Dec 13, 2011 at 13:21, Timothy Madden wrote: >> Is there a way to launch java applications (classes), without having to know >> and to specify where the .class files are installed all the time ? > > Yes, One-Jar. > > My favorite Java apps (desktop Java) are properly packaged as a single > .jar file and can be run by just issuing java -jar appname.jar. > > I think Sun should have made One-Jar part of the JDK and its use mandatory. > > http://one-jar.sourceforge.net/ > > Fiddling with the classpath feels so 1990s... And is there a way to launch such a jar from PATH for example, or without knowing the specific install location ? I vaguely remember there was some way to add a new executable format to a system (user-mode only), but I am not sure that making all .jar files a directly "executable" format, like ELF/PE ones, is appropriate or is good practice. Maybe a .jar file will override some existing system command this way... Thank you, Timothy Madden From fcassia at gmail.com Wed Dec 21 21:37:28 2011 From: fcassia at gmail.com (Fernando Cassia) Date: Wed, 21 Dec 2011 18:37:28 -0300 Subject: Is there a better alternative for -cp/CLASSPATH ? In-Reply-To: References: <4EE79069.3040707@redhat.com> Message-ID: On Wed, Dec 21, 2011 at 11:18, Timothy Madden wrote: > I do believe a monolithic JDK can have disadvantages for non-PC systems, I do not know what you mean by "monolithic jdk". What I?m talking about is having the java app delivered as a single .jar file. This has nothing to do with "PC or not PC". I?ve run such apps under Windows, IBM OS/2, Linux desktop, and embedded Linux. Java ME mobile apps are also delivered as a single .jar file. The key in all instances is defining the default class in the .jar ?s Manifest file http://ideoplex.com/id/1339/building-an-executable-jar-with-ant FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code From ahughes at redhat.com Thu Dec 22 23:42:05 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 22 Dec 2011 23:42:05 +0000 Subject: OpenJDK Members Message-ID: <20111222234202.GE22074@rivendell.middle-earth.co.uk> The bylaws (http://openjdk.java.net/bylaws#_8) state that new OpenJDK members can be: "nominated to be an OpenJDK Member by an existing OpenJDK Member. Such a nomination must be approved by a Three-Vote Consensus of the OpenJDK Members." However, it's not clear as to where this voting takes place. There appears to be a members mailing list (http://mail.openjdk.java.net/mailman/listinfo/members) but it's practically a ghost town. What is the procedure for initiating such a vote? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From artem.ananiev at oracle.com Fri Dec 23 13:30:58 2011 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 23 Dec 2011 17:30:58 +0400 Subject: OpenJDK Members In-Reply-To: <20111222234202.GE22074@rivendell.middle-earth.co.uk> References: <20111222234202.GE22074@rivendell.middle-earth.co.uk> Message-ID: <4EF48292.8000203@oracle.com> On 12/23/2011 3:42 AM, Dr Andrew John Hughes wrote: > The bylaws (http://openjdk.java.net/bylaws#_8) state that new OpenJDK > members can be: > > "nominated to be an OpenJDK Member by an existing OpenJDK Member. Such > a nomination must be approved by a Three-Vote Consensus of the OpenJDK > Members." > > However, it's not clear as to where this voting takes place. There > appears to be a members mailing list (http://mail.openjdk.java.net/mailman/listinfo/members) > but it's practically a ghost town. > > What is the procedure for initiating such a vote? Doesn't it make more sense to nominate people to certain Group/Project, on the corresponding Group/Project alias? Thanks, Artem > Thanks, From mark.reinhold at oracle.com Fri Dec 23 17:13:27 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 23 Dec 2011 09:13:27 -0800 Subject: OpenJDK Members In-Reply-To: ahughes@redhat.com; Thu, 22 Dec 2011 23:42:05 GMT; <20111222234202.GE22074@rivendell.middle-earth.co.uk> Message-ID: <20111223171327.0AB44F7F@eggemoggin.niobe.net> 2011/12/22 15:42 -0800, ahughes at redhat.com: > The bylaws (http://openjdk.java.net/bylaws#_8) state that new OpenJDK > members can be: ... > > However, it's not clear as to where this voting takes place. There > appears to be a members mailing list (http://mail.openjdk.java.net/mailman/listinfo/members) > but it's practically a ghost town. It may be quiet, but that list is the correct place to hold a vote for a new OpenJDK Member. > What is the procedure for initiating such a vote? http://openjdk.java.net/groups/#openjdk-member - Mark From david.holmes at oracle.com Fri Dec 23 21:45:57 2011 From: david.holmes at oracle.com (David Holmes) Date: Sat, 24 Dec 2011 07:45:57 +1000 Subject: OpenJDK Members In-Reply-To: <20111223171327.0AB44F7F@eggemoggin.niobe.net> References: <20111223171327.0AB44F7F@eggemoggin.niobe.net> Message-ID: <4EF4F695.1070608@oracle.com> On 24/12/2011 3:13 AM, mark.reinhold at oracle.com wrote: > 2011/12/22 15:42 -0800, ahughes at redhat.com: >> The bylaws (http://openjdk.java.net/bylaws#_8) state that new OpenJDK >> members can be: ... >> >> However, it's not clear as to where this voting takes place. There >> appears to be a members mailing list (http://mail.openjdk.java.net/mailman/listinfo/members) >> but it's practically a ghost town. > > It may be quiet, but that list is the correct place to hold a vote > for a new OpenJDK Member. Shouldn't that list be populated with the current set of JDK members? David ----- >> What is the procedure for initiating such a vote? > > http://openjdk.java.net/groups/#openjdk-member From mark.reinhold at oracle.com Fri Dec 23 22:51:13 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 23 Dec 2011 14:51:13 -0800 Subject: OpenJDK Members In-Reply-To: david.holmes@oracle.com; Sat, 24 Dec 2011 07:45:57 +1000; <4EF4F695.1070608@oracle.com> Message-ID: <20111223225113.B8BFA10B2@eggemoggin.niobe.net> 2011/12/23 13:45 -0800, david.holmes at oracle.com: > Shouldn't that list be populated with the current set of JDK members? It is. What makes you think it isn't? - Mark From david.holmes at oracle.com Fri Dec 23 23:27:59 2011 From: david.holmes at oracle.com (David Holmes) Date: Sat, 24 Dec 2011 09:27:59 +1000 Subject: OpenJDK Members In-Reply-To: <20111223225113.B8BFA10B2@eggemoggin.niobe.net> References: <20111223225113.B8BFA10B2@eggemoggin.niobe.net> Message-ID: <4EF50E7F.8030300@oracle.com> On 24/12/2011 8:51 AM, mark.reinhold at oracle.com wrote: > 2011/12/23 13:45 -0800, david.holmes at oracle.com: >> Shouldn't that list be populated with the current set of JDK members? > > It is. What makes you think it isn't? I didn't seem to be on it when I checked, but turns out I was using the wrong password for that list. Sorry for the noise. David > - Mark From mark at klomp.org Tue Dec 27 22:28:52 2011 From: mark at klomp.org (Mark Wielaard) Date: Tue, 27 Dec 2011 23:28:52 +0100 Subject: Free Java @ FOSDEM 2012 (CFP deadline end this year!) Message-ID: <20111227222852.GB7485@toonder.wildebeest.org> The end of 2011 is near. The Free Java Momentum will be even bigger in 2012. Have you made your new year's resolutions yet? And is attending Free Java @ FOSDEM 2012 on Feb 4 and 5 one of them? http://wiki.debian.org/Java/DevJam/2012/Fosdem Or are you even more ambitious and will you submit a talk proposal? Then please make sure you submit an abstract before the end of the year to fosdem at developer.classpath.org. Full instructions can be found at: http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation -------------- next part -------------- An embedded message was scrubbed... From: Mark Wielaard Subject: Call for participation: Free Java @ FOSDEM 2012 Date: Sun, 11 Dec 2011 14:11:48 +0100 Size: 1838 URL: From brian.goetz at oracle.com Fri Dec 30 16:50:50 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 30 Dec 2011 11:50:50 -0500 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: Message-ID: <4EFDEBEA.2070306@oracle.com> I have a number of issues with the proposed workflow. 1. At the risk of starting with a silly one, Dispatched? Really? Yes, everyone who has worked at Sun over time has learned what Dispatched means, but it is a constant question for newcomers, and given that one of the major motivations for a new bug system is externalizing the process so that the community can play too, we should err on the side of using terms that are understood by the community. Every other bug system calls this "New". Using a term that no one understands sends the wrong message about who this system is for. 2. Accepted/Understood. I think these should be merged into something like "Open". The distinction between Accepted And Understood is a very fuzzy one; in reality there are many shades of grey between them and achieving understanding often happens gradually over time. Having a bug transition from one to the other does not provide a great deal of additional information to external stakeholders, which is mostly the point of bug state transitions. A good way to evaluate whether this state carries its weight is: what impact does the transition from Accepted to Understood have to non-Dev stakeholders, such as the bug submitter or QE? I think very little, since Understood does not mean that resources have been allocated to the bug. And the names Accepted and Understood carry connotations that are easily misinterpreted as committments to fix. 3. Fixed. Having this be the end of the line seems excessively Dev-centric. The workflow should support not only Dev, but QE, RE, and other participants as well. I think a better fit for our process would be Fix Available, which indicates that Dev has pushed a changeset for the fix, but that changeset has not necessarily been integrated (RE) or tested (QE). I would think that the transition after an engineer pushes a changeset would be to move it to some Fix Available state, and transfer ownership of the issue to the responsible integrator. (Similarly, once integrated, ownership of the issue should go to QE to for verification, who can close the issue.) This more easily enables reports to show where in the organization the work currently is, where the bottlenecks are, etc. Bug states (and other top-level metadata, such as owner) should provide a simple view of not only where the bug is in its lifecycle, but who in the organization has ownership now. As a bug progresses, ownership should transition from its creator to a triage team to a component team to a responsible engineer to integration to testing to delivery. (Though it may not be necessary to reflect every one of those transitions as part of the state.) Similarly, when an engineer or integrator or QE is done with their part, they should be able to *get it off their plate.* The workflow should reflect who has ownership of the issue between the time Dev has pushed a fix and the time it is integrated; pretending that Dev still owns the issue (and that RE/QE does not) presents a distorted view of the process. 4. There are a number of other things that are not reflected in this draft workflow, including: - What happens before a bug hits the "new" state? What is the equivalent of today's "webbugs" system? Do we anticipate creating bugs in this project, or doing what most large projects do, which is have a front-end triage project whose final workflow stage is to move it to the New state in the main project? - What are the access control rules for state transitions? Who can create issues? Who can assign them to engineers? Who can set priorities or target fix versions? How does this play into JIRAs security policies? - What is our plan for handling when a fix has to be integrated into multiple codelines? There was talk of a "normalized" data model for this (which made a lot of sense to me) but I don't see any mention of that here. I look forward to seeing future drafts. From richard.bair at oracle.com Sat Dec 31 15:48:01 2011 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 31 Dec 2011 07:48:01 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EFDEBEA.2070306@oracle.com> References: <4EFDEBEA.2070306@oracle.com> Message-ID: On Dec 30, 2011, at 8:50 AM, Brian Goetz wrote: > I have a number of issues with the proposed workflow. > > 1. At the risk of starting with a silly one, Dispatched? Really? Yes, everyone who has worked at Sun over time has learned what Dispatched means, but it is a constant question for newcomers, and given that one of the major motivations for a new bug system is externalizing the process so that the community can play too, we should err on the side of using terms that are understood by the community. Every other bug system calls this "New". Using a term that no one understands sends the wrong message about who this system is for. Completely agree. > 2. Accepted/Understood. I think these should be merged into something like "Open". The distinction between Accepted And Understood is a very fuzzy one; in reality there are many shades of grey between them and achieving understanding often happens gradually over time. Having a bug transition from one to the other does not provide a great deal of additional information to external stakeholders, which is mostly the point of bug state transitions. A good way to evaluate whether this state carries its weight is: what impact does the transition from Accepted to Understood have to non-Dev stakeholders, such as the bug submitter or QE? I think very little, since Understood does not mean that resources have been allocated to the bug. And the names Accepted and Understood carry connotations that are easily misinterpreted as committments to fix. Completely agree. I don't see any value in the various "sub states" and I think you captured well the reason. Richard From georges.saab at oracle.com Sat Dec 31 18:13:03 2011 From: georges.saab at oracle.com (Georges Saab) Date: Sat, 31 Dec 2011 10:13:03 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: References: <4EFDEBEA.2070306@oracle.com> Message-ID: <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> On 31 dec 2011, at 07:48, Richard Bair wrote: > On Dec 30, 2011, at 8:50 AM, Brian Goetz wrote: > >> I have a number of issues with the proposed workflow. >> >> 1. At the risk of starting with a silly one, Dispatched? Really? Yes, everyone who has worked at Sun over time has learned what Dispatched means, but it is a constant question for newcomers, and given that one of the major motivations for a new bug system is externalizing the process so that the community can play too, we should err on the side of using terms that are understood by the community. Every other bug system calls this "New". Using a term that no one understands sends the wrong message about who this system is for. > > Completely agree. > >> 2. Accepted/Understood. I think these should be merged into something like "Open". The distinction between Accepted And Understood is a very fuzzy one; in reality there are many shades of grey between them and achieving understanding often happens gradually over time. Having a bug transition from one to the other does not provide a great deal of additional information to external stakeholders, which is mostly the point of bug state transitions. A good way to evaluate whether this state carries its weight is: what impact does the transition from Accepted to Understood have to non-Dev stakeholders, such as the bug submitter or QE? I think very little, since Understood does not mean that resources have been allocated to the bug. And the names Accepted and Understood carry connotations that are easily misinterpreted as committments to fix. > > Completely agree. I don't see any value in the various "sub states" and I think you captured well the reason. Do we have to chose one or the other? I have used systems that had both a high level state (New, Open, Closed) and substates useful to one or more groups to keep track of where the bug is 'right now' or giving more information (for instance -- Closed:Fixed vs Closed:Verified vs Closed:Will not fix). I agree completely that some of the current status terms are misleading or confusing at best (accepted being perhaps the worst offender). As such we should take care in choosing names and perhaps most importantly have clear links to help text describing what each of these is supposed to mean. > > Richard From brian.goetz at oracle.com Sat Dec 31 18:16:48 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 31 Dec 2011 13:16:48 -0500 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> References: <4EFDEBEA.2070306@oracle.com> <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> Message-ID: <4EFF5190.2040605@oracle.com> >> Completely agree. I don't see any value in the various "sub states" >> and I think you captured well the reason. > > Do we have to chose one or the other? I have used systems that had > both a high level state (New, Open, Closed) and substates useful to > one or more groups to keep track of where the bug is 'right now' or > giving more information (for instance -- Closed:Fixed vs > Closed:Verified vs Closed:Will not fix). I agree completely that > some of the current status terms are misleading or confusing at best > (accepted being perhaps the worst offender). As such we should take > care in choosing names and perhaps most importantly have clear links > to help text describing what each of these is supposed to mean. A good JIRA rule is: don't design a workflow where any query that anyone ever has to do regularly as part of their job includes examining substates. If we want to use substates as a form of enumerated documentation options, that's fine; Closed:Verified vs Close:WillNotFix is a good example, since the most common consumer will be a human looking at the summary page to learn the disposition. But if our processes need to distinguish between Open:FixUnderstood and Open:IHaveNoFrigginIdea, we're creating the sort of problem that tends to lead to the creation of boundary systems. From georges.saab at oracle.com Sat Dec 31 18:45:57 2011 From: georges.saab at oracle.com (Georges Saab) Date: Sat, 31 Dec 2011 10:45:57 -0800 (PST) Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EFF5190.2040605@oracle.com> References: <4EFDEBEA.2070306@oracle.com> <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> <4EFF5190.2040605@oracle.com> Message-ID: <1052D6AB-60BC-4871-BC52-9F2750C7F1A6@oracle.com> I don't think the sub-states matter to any processes used on a daily basis. I do think they can add information (without requiring detailed reading of the bug comments) that can help find outliers that need attention. For instance, if we have two sub-states for New (unqualified and qualified, the distinction being initial triage ensuring that the information in the bug report is sufficient to do something with it), we could have a desired SLA (service level agreement) on the time to move between these. If we are consistently failing to meet this in a particular area then it shows us we need more investment there (or we need to decide we can accept a less aggressive SLA). This kind of query can easily be automated. Maybe this is exactly the kind of boundary system you are worried about, though? (yes, usual caveats about be careful what you measure and lets not get so excited about measuring things that we create a false economy or think that the measuring is more important than the work being measured). On 31 dec 2011, at 10:16, Brian Goetz wrote: >>> Completely agree. I don't see any value in the various "sub states" >>> and I think you captured well the reason. >> >> Do we have to chose one or the other? I have used systems that had >> both a high level state (New, Open, Closed) and substates useful to >> one or more groups to keep track of where the bug is 'right now' or >> giving more information (for instance -- Closed:Fixed vs >> Closed:Verified vs Closed:Will not fix). I agree completely that >> some of the current status terms are misleading or confusing at best >> (accepted being perhaps the worst offender). As such we should take >> care in choosing names and perhaps most importantly have clear links >> to help text describing what each of these is supposed to mean. > > A good JIRA rule is: don't design a workflow where any query that anyone ever has to do regularly as part of their job includes examining substates. > > If we want to use substates as a form of enumerated documentation options, that's fine; Closed:Verified vs Close:WillNotFix is a good example, since the most common consumer will be a human looking at the summary page to learn the disposition. But if our processes need to distinguish between Open:FixUnderstood and Open:IHaveNoFrigginIdea, we're creating the sort of problem that tends to lead to the creation of boundary systems. From brian.goetz at oracle.com Sat Dec 31 19:08:28 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 31 Dec 2011 14:08:28 -0500 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <1052D6AB-60BC-4871-BC52-9F2750C7F1A6@oracle.com> References: <4EFDEBEA.2070306@oracle.com> <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> <4EFF5190.2040605@oracle.com> <1052D6AB-60BC-4871-BC52-9F2750C7F1A6@oracle.com> Message-ID: <4EFF5DAC.2060907@oracle.com> > For instance, if we have two sub-states for New (unqualified and qualified, the distinction being initial triage > ensuring that the information in the bug report is sufficient to do something with it), we could have a desired > SLA (service level agreement) on the time to move between these. If we are consistently failing to meet this > in a particular area then it shows us we need more investment there (or we need to decide we can accept a > less aggressive SLA). This kind of query can easily be automated. Maybe this is exactly the kind of boundary > system you are worried about, though? What I'm worried about is mostly the discovery effort of individual managers trying to craft their own queries, and each getting it slightly different. Substates increase the likelihood of this, which leads to the call for centralized boundary systems. If such queries can be canned and reproduced to dashboards, or the constituency for them is small, then it probably works fine. From georges.saab at oracle.com Sat Dec 31 19:22:42 2011 From: georges.saab at oracle.com (Georges Saab) Date: Sat, 31 Dec 2011 11:22:42 -0800 Subject: OpenJDK bug database: DRAFT Developer Workflow In-Reply-To: <4EFF5DAC.2060907@oracle.com> References: <4EFDEBEA.2070306@oracle.com> <7E88EE5F-4CCF-4F54-AC54-22D90FE5E83D@oracle.com> <4EFF5190.2040605@oracle.com> <1052D6AB-60BC-4871-BC52-9F2750C7F1A6@oracle.com> <4EFF5DAC.2060907@oracle.com> Message-ID: <7D869244-198C-464E-AF6D-8825D96872B8@oracle.com> agree completely, suggestion is that we have standard queries for common operations at each level (release, component, individual) such as initial triage, component team triage, release team triage, deferral requests, 'my open issues', etc. On 31 dec 2011, at 11:08, Brian Goetz wrote: >> For instance, if we have two sub-states for New (unqualified and qualified, the distinction being initial triage >> ensuring that the information in the bug report is sufficient to do something with it), we could have a desired >> SLA (service level agreement) on the time to move between these. If we are consistently failing to meet this >> in a particular area then it shows us we need more investment there (or we need to decide we can accept a >> less aggressive SLA). This kind of query can easily be automated. Maybe this is exactly the kind of boundary >> system you are worried about, though? > > What I'm worried about is mostly the discovery effort of individual managers trying to craft their own queries, and each getting it slightly different. Substates increase the likelihood of this, which leads to the call for centralized boundary systems. If such queries can be canned and reproduced to dashboards, or the constituency for them is small, then it probably works fine. >