From roger.lewis at oracle.com Thu Mar 3 14:03:51 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Thu, 03 Mar 2011 14:03:51 -0800 Subject: OpenJDK Bug Tracking Project Message-ID: <4D701047.5030906@oracle.com> Hello, A draft of the OpenJDK Bug Tracking Project is now available. For further information please see: http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html As it says in the draft, we would like to have requirements raised and discussed. Also, while it may be tempting to discuss the benefits of particular bug tracking systems, we would like to limit the discussion to the requirements. Suggesting a system to be considered is fine, but that is not the intent at this time. Thank you, Roger From gnu_andrew at member.fsf.org Thu Mar 3 14:11:55 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Thu, 3 Mar 2011 22:11:55 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D701047.5030906@oracle.com> References: <4D701047.5030906@oracle.com> Message-ID: On 3 March 2011 22:03, Roger Lewis wrote: > Hello, > > A draft of the OpenJDK Bug Tracking Project is now available. ?For further > information please see: > http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html > > As it says in the draft, we would like to have requirements raised and > discussed. Also, while it may be tempting to discuss the benefits of > particular bug tracking systems, we would like to limit the discussion to > the requirements. Suggesting a system to be considered ?is fine, but that is > not the intent at this time. > > Thank you, > Roger > It should be a Free Software/Open Source solution with equal access to all, both inside and outside Oracle. To quote the original OpenJDK bug tracking project (http://openjdk.java.net/groups/web/bugzilla.html), this allows you to 'fully embrace the Open Source paradigm'. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From Ulf.Zibis at gmx.de Fri Mar 4 04:59:38 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 04 Mar 2011 13:59:38 +0100 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D701047.5030906@oracle.com> References: <4D701047.5030906@oracle.com> Message-ID: <4D70E23A.20909@gmx.de> *o* Supports a rich query language I like to add: *o* Supports a rich query Web form Example: http://netbeans.org/bugzilla/query.cgi?format=advanced -Ulf Am 03.03.2011 23:03, schrieb Roger Lewis: > Hello, > > A draft of the OpenJDK Bug Tracking Project is now available. For further information please see: > http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html > > As it says in the draft, we would like to have requirements raised and discussed. Also, while it > may be tempting to discuss the benefits of particular bug tracking systems, we would like to limit > the discussion to the requirements. Suggesting a system to be considered is fine, but that is not > the intent at this time. > > Thank you, > Roger > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20110304/ff886832/attachment.html From spoole at linux.vnet.ibm.com Fri Mar 4 07:41:15 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Fri, 04 Mar 2011 15:41:15 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D701047.5030906@oracle.com> References: <4D701047.5030906@oracle.com> Message-ID: <4D71081B.6060601@linux.vnet.ibm.com> On 03/03/11 22:03, Roger Lewis wrote: > Hello, > > A draft of the OpenJDK Bug Tracking Project is now available. For > further information please see: > http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html > > As it says in the draft, we would like to have requirements raised and > discussed. Also, while it may be tempting to discuss the benefits of > particular bug tracking systems, we would like to limit the discussion > to the requirements. Suggesting a system to be considered is fine, > but that is not the intent at this time. > > Thank you, > Roger Roger - glad to see this topic on the mailing lists. Now while I understand the need to gather requirements I see little benefit in doing that in isolation. Let's be clear - there are not that many good candidates to choose from. Personally I'd rather we identified a few candidates and discussed their relative merits. Also - we need to ensure that other "non functional" aspects of these candidates are listed. Items such as "pricing", "support costs", "hardware requirements", "size of developer community" , "active development", "high quality", "development language", "licence" etc are as important in this consideration as specific functional features. My candidates Bugzilla Jira Rational Team Concert Cheers Steve From mark at klomp.org Fri Mar 4 10:38:29 2011 From: mark at klomp.org (Mark Wielaard) Date: Fri, 4 Mar 2011 19:38:29 +0100 (CET) Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D701047.5030906@oracle.com> References: <4D701047.5030906@oracle.com> Message-ID: <60986.80.101.103.228.1299263909.squirrel@gnu.wildebeest.org> Hi Roger, On Thu, March 3, 2011 23:03, Roger Lewis wrote: > A draft of the OpenJDK Bug Tracking Project is now available. For > further information please see: > http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html It might be easier to have these requirements just posted to the list for discussion. Here are the requirements listed so far: Below are high-level requirements that have been collected: > * Web Services or REST APIs for querying and updating bugs And I assume creating? > * Supports a rich query language > * Web client > * Email notification for new bugs > * Email notification for bug state changes RSS feed for bugs based on query? Some way to create/share "pre-canned" queries of bugs? Would be nice if email can also be used for adding comments, etc. Public autobuilders could send an email or do a update of a bug when a build with a patch referencing a bug is successful (or failed). > * Able to look up old bug Ids > * Available 24 hours a day, 7 days a week (not including maintenance and downtime) > * Provides the ability to vote and comment on a bug Why would you voting? And what kind of voting do you have in mind? > * User role will define what access user has to data Role Types: > 1. View Bugs (by far the largest group): Anyone in the world with a web browser And through the mailinglist and rss feeds I hope? > 2. Vote, watch, add comments, submit bugs: End users, Java Developers, OpenJDK developers Is there really a difference between these groups of users? > 3. Update bugs: Java Developers who submitted the bug, OpenJDK developers > 4. Ownership of bugs: Open JDK Developers How do you define "Ownership"? > 6. Create/Change categories, manage users, manage data , Admins What are the requirements for the categories? Do you expect some correlation between categories and users groups? > * All JDK bugs (open and closed) will be migrated to the new system. This includes bugs back to version 1.0 That would be nice, but it might be a lot of work and constrain how new bugs get added. Maybe these could all be "archived" bugs, that you could lookup, but not change anymore. Hopefully this also means we finally get all bugs public and that bugs are not made inaccessible to some people as is currently the case on bugs.sun.com (so frustrating...) > * Must be able to support large volumes of bugs up to 1M bugs (plan for 10+ years). The current JDK tracking system has about 120,000 Nice to have things might be: - Version tracking of issues, related to openjdk releases/branches. - Known working/failing versions. - Milestones? - Attaching files, patches, etc. - Inter bug tracking (so you can reference bugs from other project, downstream/upstream, etc.), with possible notification when such a referenced bug gets updated and/or updating other bug trackers when this bug report gets updated. - dependencies between bugs, so you can create tracking bugs for some feature, which is only completed when all bugs that it depend on are resolved. - Bonus points for having nice dependency graphs. - mercurial integration, so that when a patch that references a bug is committed to some tree it can add a note to the bug report. - bug group category or user watching, so one can follow work (useful when you take over someone work for a while, or need to do Q/A for some category of bugs). - have some way to mark/show frequently occurring bugs, so you can easily reference known issues with a simple URL. - integration with patch viewer/review process/mercurial so patches attached to bugs can easily be reviewed, changed and/or committed. Cheers, Mark From mark at klomp.org Fri Mar 4 10:41:06 2011 From: mark at klomp.org (Mark Wielaard) Date: Fri, 4 Mar 2011 19:41:06 +0100 (CET) Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D71081B.6060601@linux.vnet.ibm.com> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> Message-ID: <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> Hi Steve, On Fri, March 4, 2011 16:41, Steve Poole wrote: > On 03/03/11 22:03, Roger Lewis wrote: >> As it says in the draft, we would like to have requirements raised and >> discussed. Also, while it may be tempting to discuss the benefits of >> particular bug tracking systems, we would like to limit the discussion >> to the requirements. Suggesting a system to be considered is fine, >> but that is not the intent at this time. > > Now while I understand the need to gather requirements I see little > benefit in doing that in isolation. Let's be clear - there are not that > many good candidates to choose from. Personally I'd rather we > identified a few candidates and discussed their relative merits. Yeah, I agree it is easier to discuss these things against a few concrete candidates. > My candidates > > Bugzilla > Jira > Rational Team Concert That last two are non-free proprietary products so out of scope. But I agree that Bugzilla is pretty nice and powerful. Cheers, Mark From spoole at linux.vnet.ibm.com Sun Mar 6 02:56:57 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Sun, 06 Mar 2011 10:56:57 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> Message-ID: <4D736879.9090701@linux.vnet.ibm.com> On 04/03/11 18:41, Mark Wielaard wrote: > Hi Steve, > > On Fri, March 4, 2011 16:41, Steve Poole wrote: >> On 03/03/11 22:03, Roger Lewis wrote: >>> As it says in the draft, we would like to have requirements raised and >>> discussed. Also, while it may be tempting to discuss the benefits of >>> particular bug tracking systems, we would like to limit the discussion >>> to the requirements. Suggesting a system to be considered is fine, >>> but that is not the intent at this time. >> Now while I understand the need to gather requirements I see little >> benefit in doing that in isolation. Let's be clear - there are not that >> many good candidates to choose from. Personally I'd rather we >> identified a few candidates and discussed their relative merits. > Yeah, I agree it is easier to discuss these things against a few > concrete candidates. > >> My candidates >> >> Bugzilla >> Jira >> Rational Team Concert > That last two are non-free proprietary products so out of scope. Why does that make them out of scope? > But I agree that Bugzilla is pretty nice and powerful. > > Cheers, > > Mark > From mark at klomp.org Sun Mar 6 06:26:00 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 6 Mar 2011 15:26:00 +0100 (CET) Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D736879.9090701@linux.vnet.ibm.com> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> <4D736879.9090701@linux.vnet.ibm.com> Message-ID: <42984.80.101.103.228.1299421560.squirrel@gnu.wildebeest.org> On Sun, March 6, 2011 11:56, Steve Poole wrote: > On 04/03/11 18:41, Mark Wielaard wrote: >>> Let's be clear - there are not that >>> many good candidates to choose from. Personally I'd rather we >>> identified a few candidates and discussed their relative merits. >> >> Yeah, I agree it is easier to discuss these things against a few >> concrete candidates. >> >>> My candidates >>> >>> Bugzilla >>> Jira >>> Rational Team Concert >> That last two are non-free proprietary products so out of scope. > > Why does that make them out of scope? Simply because openjdk is a free software project and community. As Andrew pointed out, the openjdk bug tracking FAQ explicitly states proprietary solutions like Jira are out of scope: "The other primary reason: we want to fully embrace the Open Source paradigm" http://openjdk.java.net/groups/web/bugzilla.html#FAQ >> But I agree that Bugzilla is pretty nice and powerful. >> >> Cheers, >> >> Mark From fw at deneb.enyo.de Sun Mar 6 07:12:42 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 06 Mar 2011 16:12:42 +0100 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D71081B.6060601@linux.vnet.ibm.com> (Steve Poole's message of "Fri, 04 Mar 2011 15:41:15 +0000") References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> Message-ID: <87k4gc4711.fsf@mid.deneb.enyo.de> * Steve Poole: > Rational Team Concert It seems that operating system and browser support for the client is rather poor, according to . From mark at klomp.org Sun Mar 6 07:44:37 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 6 Mar 2011 16:44:37 +0100 (CET) Subject: Moderated distro-pkg-dev message disappeared? Message-ID: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> Hi, Just saw what looked like a message to distro-pkg-dev disappear. I did get a message about it waiting moderator approval (see attached). And since I am a moderator I looked in the moderator queue, but it wasn't there. Any idea what has happened to that message. Or how I would be able to better track such issues myself? Thanks, Mark -------------- next part -------------- An embedded message was scrubbed... From: distro-pkg-dev-bounces at openjdk.java.net Subject: Your message to distro-pkg-dev awaits moderator approval Date: Sun, 06 Mar 2011 06:35:16 -0800 Size: 2533 Url: http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20110306/f94682d0/attachment.nws From spoole at linux.vnet.ibm.com Sun Mar 6 08:49:56 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Sun, 06 Mar 2011 16:49:56 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <42984.80.101.103.228.1299421560.squirrel@gnu.wildebeest.org> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> <4D736879.9090701@linux.vnet.ibm.com> <42984.80.101.103.228.1299421560.squirrel@gnu.wildebeest.org> Message-ID: <4D73BB34.6030608@linux.vnet.ibm.com> On 06/03/11 14:26, Mark Wielaard wrote: > On Sun, March 6, 2011 11:56, Steve Poole wrote: >> On 04/03/11 18:41, Mark Wielaard wrote: >>>> Let's be clear - there are not that >>>> many good candidates to choose from. Personally I'd rather we >>>> identified a few candidates and discussed their relative merits. >>> Yeah, I agree it is easier to discuss these things against a few >>> concrete candidates. >>> >>>> My candidates >>>> >>>> Bugzilla >>>> Jira >>>> Rational Team Concert >>> That last two are non-free proprietary products so out of scope. >> Why does that make them out of scope? > Simply because openjdk is a free software project and community. > As Andrew pointed out, the openjdk bug tracking FAQ explicitly > states proprietary solutions like Jira are out of scope: > "The other primary reason: we want to fully embrace the Open > Source paradigm" > http://openjdk.java.net/groups/web/bugzilla.html#FAQ > That's interesting, Personally I don't see a problem with using non free systems. Infrastructure of any sort is never free - someone always has to pay for it. Oracle or IBM or some other sponsor has to be willing to stump up the cash for the required hosting at the very least. If they are willing to go further and spend money on a licence/support for a system we desire - why should the OpenJDK community turn down such an opportunity? >>> But I agree that Bugzilla is pretty nice and powerful. >>> >>> Cheers, >>> >>> Mark > From spoole at linux.vnet.ibm.com Sun Mar 6 09:06:04 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Sun, 06 Mar 2011 17:06:04 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <87k4gc4711.fsf@mid.deneb.enyo.de> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> <87k4gc4711.fsf@mid.deneb.enyo.de> Message-ID: <4D73BEFC.5060906@linux.vnet.ibm.com> On 06/03/11 15:12, Florian Weimer wrote: > * Steve Poole: > >> Rational Team Concert > It seems that operating system and browser support for the client is > rather poor, according to. RTC is pretty sophisticated - it does a lot more than bug tracking including having its own source control system. I will have to remember to check for Solaris support when I look at these sorts of things in the future :-) From a bug tacking point of view I believe everything can be down via the browser. What extra browser support were you looking for? (Chrome perhaps?) Or just a wider range for version support of Firefox and IE? Just to be clear my list is sort of in order. I pick Bugzilla first because it has the longest, most successful pedigree even though I find configuring it a pain. I go with Jira second as it is runs on Java , is high quality , has great support and is very configurable. I Iisted RTC because (not withstanding who I work for) I actually like it. I can't speak for the source control side but the bug management and process management support is first class. From mark at klomp.org Sun Mar 6 09:16:39 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 06 Mar 2011 18:16:39 +0100 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D73BB34.6030608@linux.vnet.ibm.com> References: <4D701047.5030906@oracle.com> <4D71081B.6060601@linux.vnet.ibm.com> <51211.80.101.103.228.1299264066.squirrel@gnu.wildebeest.org> <4D736879.9090701@linux.vnet.ibm.com> <42984.80.101.103.228.1299421560.squirrel@gnu.wildebeest.org> <4D73BB34.6030608@linux.vnet.ibm.com> Message-ID: <1299431799.4966.6.camel@springer.wildebeest.org> On Sun, 2011-03-06 at 16:49 +0000, Steve Poole wrote: > On 06/03/11 14:26, Mark Wielaard wrote: > > On Sun, March 6, 2011 11:56, Steve Poole wrote: > >> On 04/03/11 18:41, Mark Wielaard wrote: > >>> That last two are non-free proprietary products so out of scope. > >> Why does that make them out of scope? > > Simply because openjdk is a free software project and community. > > As Andrew pointed out, the openjdk bug tracking FAQ explicitly > > states proprietary solutions like Jira are out of scope: > > "The other primary reason: we want to fully embrace the Open > > Source paradigm" > > http://openjdk.java.net/groups/web/bugzilla.html#FAQ > > > That's interesting, Personally I don't see a problem with using non > free systems. Infrastructure of any sort is never free - someone always > has to pay for it. Oracle or IBM or some other sponsor has to be > willing to stump up the cash for the required hosting at the very > least. If they are willing to go further and spend money on a > licence/support for a system we desire - why should the OpenJDK > community turn down such an opportunity? I wouldn't mind at all if someone would help with the hosting or hardware costs. You are right such things aren't free/gratis. But it also isn't such a big deal. Currently for IcedTea we have both covered by volunteer (non-corporate) contributions. But it is something entirely different if the infrastructure itself would be non-free/proprietary. Users, especially those maintaining the infrastructure setup, should have the same freedoms as we are promoting with the OpenJDK project itself. FWIW. The whole IcedTea infrastructure is deployed based on free software solutions. As are lots of other open source projects. Cheers, Mark From tim.bell at gmail.com Sun Mar 6 09:29:40 2011 From: tim.bell at gmail.com (Tim Bell) Date: Sun, 6 Mar 2011 09:29:40 -0800 Subject: Moderated distro-pkg-dev message disappeared? In-Reply-To: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> References: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> Message-ID: Hi Mark > Just saw what looked like a message to distro-pkg-dev disappear. > I did get a message about it waiting moderator approval (see > attached). And since I am a moderator I looked in the moderator > queue, but it wasn't there. Any idea what has happened to that > message. That was the SPAM killer cron job: Discarded held msg #1442 for list distro-pkg-dev I will requeue the mail and tweak the SPAM filter. (nothing was actually deleted - the message is renamed into the SPAM directory). > Or how I would be able to better track such issues myself? Unfortunately, you need command line access to look at the log files. Tim From mark at klomp.org Sun Mar 6 09:46:29 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 6 Mar 2011 18:46:29 +0100 (CET) Subject: Moderated distro-pkg-dev message disappeared? In-Reply-To: References: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> Message-ID: <60679.80.101.103.228.1299433589.squirrel@gnu.wildebeest.org> Hi Tim, Thanks for the fast response! On Sun, March 6, 2011 18:29, Tim Bell wrote: >> Just saw what looked like a message to distro-pkg-dev disappear. >> I did get a message about it waiting moderator approval (see >> attached). And since I am a moderator I looked in the moderator >> queue, but it wasn't there. Any idea what has happened to that >> message. > > That was the SPAM killer cron job: > > Discarded held msg #1442 for list distro-pkg-dev What made it decide to discard it? I can tweak the script that sends the commit message if necessary. > I will requeue the mail and tweak the SPAM filter. (nothing was > actually deleted - the message is renamed into the SPAM directory). Thanks. >> Or how I would be able to better track such issues myself? > > Unfortunately, you need command line access to look at the log files. I am not afraid of the command line :) Just don't know how to get at it. Thanks, Mark From tim.bell at gmail.com Sun Mar 6 10:20:41 2011 From: tim.bell at gmail.com (Tim Bell) Date: Sun, 6 Mar 2011 10:20:41 -0800 Subject: Moderated distro-pkg-dev message disappeared? In-Reply-To: <60679.80.101.103.228.1299433589.squirrel@gnu.wildebeest.org> References: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> <60679.80.101.103.228.1299433589.squirrel@gnu.wildebeest.org> Message-ID: Hi Mark >> That was the SPAM killer cron job: >> >> ? ? ? Discarded held msg #1442 for list distro-pkg-dev > > What made it decide to discard it? I can tweak the script that > sends the commit message if necessary. The reason the message was held in the first place was that user 'mark at icedtea.classpath.org' was not subscribed to distro-pkg-dev. This happens when the mercurial username != the subscriber username. When I approved the held message this time around, I ticked the 'always accept email from this user' box, so future messages won't be held. The cron SPAM filter only looks at held messages. What triggered it was the word 'officially' in the held message. I removed that word from the regex as it is too general. Other strings such as 'C L I C K H E R E' are excellent predictors for SPAM. > I am not afraid of the command line :) > Just don't know how to get at it. Unfortunately, that is not mine to give out. Check with Mark Reinhold. Tim From johan.walles at oracle.com Wed Mar 9 01:56:07 2011 From: johan.walles at oracle.com (Johan Walles) Date: Wed, 09 Mar 2011 10:56:07 +0100 Subject: OpenJDK Bug Tracking Project Message-ID: <4D774EB7.2090707@oracle.com> Hi! If we enable voting, the document [1] should describe some kind of SLA for what we do with the vote statistics. My suggestion is that we say that we commit to taking the top N voted issues seriously. Taking an issue seriously would not necessarily mean fixing it (that could be impossible), but something along the lines of: * We'll post an official analysis / opinion on the issue. * We'll post updates at least every N months. * We'll consider fixing it, and if we can't fix it we'll clearly explain why. Regards /Johan 1 - http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html From Alan.Bateman at oracle.com Wed Mar 9 02:34:21 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Mar 2011 10:34:21 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D774EB7.2090707@oracle.com> References: <4D774EB7.2090707@oracle.com> Message-ID: <4D7757AD.4080206@oracle.com> Johan Walles wrote: > Hi! > > If we enable voting, the document [1] should describe some kind of SLA > for what we do with the vote statistics. > > My suggestion is that we say that we commit to taking the top N voted > issues seriously. I don't know if other projects use voting but one concern with prioritizing based on votes is astroturfing. I'm pretty sure there's been a quite a bit of that over the years on bugs.sun.com. I also wonder about bugs that are hard for developers to distinguish from other bugs, say crashes for example where the bug report is an error log. I guess it might not be too bad if anonymous voting is not allowed but I just wonder if voting is as important as it used to be. -Alan From johan.walles at oracle.com Thu Mar 10 00:23:03 2011 From: johan.walles at oracle.com (Johan Walles) Date: Thu, 10 Mar 2011 09:23:03 +0100 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D7757AD.4080206@oracle.com> References: <4D774EB7.2090707@oracle.com> <4D7757AD.4080206@oracle.com> Message-ID: <4D788A67.2050704@oracle.com> IMO voting should definitely require logging in, otherwise we'd likely run into exactly the problems you describe. Voting is needed to prioritize community bugs. Without voting it's really hard to tell which bugs are most important to the community. And as a user, if the bug tracker doesn't support voting the only thing I can do is write "Me too!", which is unmeasurable and therefore useless. But without a clear statement on how we should treat highly voted bugs, people will just feel cheated (and rightly so) when they see highly voted bugs being ignored. Regards /Johan 2011-03-09 11:34, Alan Bateman skrev: > Johan Walles wrote: >> Hi! >> >> If we enable voting, the document [1] should describe some kind of SLA >> for what we do with the vote statistics. >> >> My suggestion is that we say that we commit to taking the top N voted >> issues seriously. > I don't know if other projects use voting but one concern with > prioritizing based on votes is astroturfing. I'm pretty sure there's > been a quite a bit of that over the years on bugs.sun.com. I also wonder > about bugs that are hard for developers to distinguish from other bugs, > say crashes for example where the bug report is an error log. I guess it > might not be too bad if anonymous voting is not allowed but I just > wonder if voting is as important as it used to be. > > -Alan From swingler at apple.com Thu Mar 10 08:21:48 2011 From: swingler at apple.com (Mike Swingler) Date: Thu, 10 Mar 2011 08:21:48 -0800 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D788A67.2050704@oracle.com> References: <4D774EB7.2090707@oracle.com> <4D7757AD.4080206@oracle.com> <4D788A67.2050704@oracle.com> Message-ID: I'd like to suggest one requirement for consideration: The ability to mass-modify the milestone, status, priority, add/remove keywords, or component groupings of individual bugs. Since the macosx-port is going to undergo many substantial changes, it would be useful to be able to effectively group bugs, to push them between engineers and milestones as the port evolves. Regards, Mike Swingler Java Engineering Apple Inc. From mark.reinhold at oracle.com Tue Mar 15 21:59:20 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 15 Mar 2011 21:59:20 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: roger.lewis@oracle.com; Thu, 03 Mar 2011 14:03:51 PST; <4D701047.5030906@oracle.com> Message-ID: <20110316045920.F25257F7@eggemoggin.niobe.net> 2011/3/3 14:03 -0800, roger.lewis at oracle.com: > A draft of the OpenJDK Bug Tracking Project is now available. For further > information please see: > http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html Thanks Roger. Here are some comments, and some additional suggested requirements. > * Web Services or REST APIs for querying and updating bugs Mark Wielaard asked whether the WS/REST API should support creating new bugs. I'd go further and say that it should support every operation that's supported by the system's usual user interfaces. It should be possible, in principle, to create an alternative UI that can completely replace the system's native UI. This ensures maximum flexibility for related programmatic systems ("boundary systems"), prevents us from being locked-in to a (potentially) stale UI, and allows for creative experimentation with alternative UIs (e.g., based upon Java FX). I also think we should have a strong preference for REST over WS-style web APIs. The big WS-* standards failed. Let's avoid them. > * Supports a rich query language > * Web client > * Email notification for new bugs > * Email notification for bug state changes E-mail notification for content updates (e.g., new comments or updated evaluations) should also be supported. I agree with Mark Wielaard that it would be nice if bugs could be updated via e-mail, but I worry about the problem of authenticating such updates. > * Able to look up old bug Ids > * Available 24 hours a day, 7 days a week (not including maintenance and downtime) > * Provides the ability to vote and comment on a bug As we've discussed in person, it's not clear to me that voting by arbitrary users is something that needs to be supported natively. If we're going to continue the Bug Parade voting tradition then that could be implemented in a separate boundary system. As to some of Mark Wielaard's other suggestions: 2011/3/4 10:38 -0800, Mark Wielaard : > Nice to have things might be: > > - Version tracking of issues, related to openjdk releases/branches. > - Known working/failing versions. > - Milestones? > - Attaching files, patches, etc. This is absolutely critical. > - Inter bug tracking (so you can reference bugs from other project, > downstream/upstream, etc.), with possible notification when such > a referenced bug gets updated and/or updating other bug trackers > when this bug report gets updated. That'd be nice, but I don't know of any system that actually implements this. > - dependencies between bugs, so you can create tracking bugs for > some feature, which is only completed when all bugs that it > depend on are resolved. I think this is critical, not only for feature-tracking bugs but also for distinct, interdependent bugs. It always annoyed me that Sun's internal bug trackers never supported dependences. Ideally one should be able to express such dependences from either direction, i.e., "this bug blocks that one", or "that bug blogs this one". > - Bonus points for having nice dependency graphs. > - mercurial integration, so that when a patch that references a > bug is committed to some tree it can add a note to the bug report. Yep. > - bug group category or user watching, so one can follow work > (useful when you take over someone work for a while, or need to > do Q/A for some category of bugs). > - have some way to mark/show frequently occurring bugs, so you > can easily reference known issues with a simple URL. > - integration with patch viewer/review process/mercurial > so patches attached to bugs can easily be reviewed, changed > and/or committed. All of these would be nice to have, but I don't see them as critical. Here a few additional requirements which I haven't yet seen anyone raise. Some of these are taken or adapted from the OpenSolaris bug-tracking requirements document [1]. - Integration with the OpenJDK people database. The bug tracker should provide a programmatic interface for adding and modifying users, so that when a contributor is added to the OpenJDK people database the system can automatically grant appropriate rights in the bug tracker, creating a new bug-tracker account if necessary or tying to an existing account. The bug tracker must also support whatever single-sign-on solution is eventually implemented for OpenJDK. - It must be possible to hide certain classes of bugs (e.g., security bugs) from all but a select few users or groups of users. - Extensibility via programmatic state-change hooks or a similar mechanism is highly desirable. Ideally such hooks should be able to veto state changes. Many of the boundary-system hacks we've built over the years against Sun's internal bug trackers solved problems that could've been more easily solved with such hooks. - A stable export format for bug reports (e.g., XML using a defined DTD or schema), for easy digestion and repurposing by boundary systems. - Both hierarchical (product/category/subcategory) and non-hierarchical (i.e., keyword or tag) bug classification. - Unicode should be fully supported in all fields of a bug report, in the query language/interface, and in the WS/REST API. Finally, I'm surprised that no one has mentioned the "CR/sub-CR" feature of Sun's current internal system. It's a bit clunky, but it makes it relatively straightforward to track related-but-distinct fixes to the same bug in different lines of code. - Mark [1] http://src.opensolaris.org/source/xref/website/spec/dts-requirements/d-dts-requirements.txt From mark.reinhold at oracle.com Wed Mar 16 08:41:27 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Mar 2011 08:41:27 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: mark.reinhold@oracle.com; Tue, 15 Mar 2011 21:59:20 PDT; <20110316045920.F25257F7@eggemoggin.niobe.net> Message-ID: <20110316154127.412CE1112@eggemoggin.niobe.net> 2011/3/15 21:59 -0700, mark.reinhold at oracle.com: > Thanks Roger. Here are some comments, and some additional suggested > requirements. > > ... Oops, forgot one: Customizable approval workflows. It should be possible to define a workflow into which a bug can be submitted for approval by a specified set of reviewers. At present we use various internal boundary systems for this sort of thing (e.g., CCC), but we need to migrate such processes outside the firewall. That'll be a lot easier if we can simply leverage the bug tracker. - Mark From jonathan.gibbons at oracle.com Wed Mar 16 08:47:01 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Mar 2011 08:47:01 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: <20110316154127.412CE1112@eggemoggin.niobe.net> References: <20110316154127.412CE1112@eggemoggin.niobe.net> Message-ID: <4D80DB75.3050105@oracle.com> On 03/16/2011 08:41 AM, mark.reinhold at oracle.com wrote: > 2011/3/15 21:59 -0700, mark.reinhold at oracle.com: >> Thanks Roger. Here are some comments, and some additional suggested >> requirements. >> >> ... > Oops, forgot one: Customizable approval workflows. It should be possible > to define a workflow into which a bug can be submitted for approval by a > specified set of reviewers. At present we use various internal boundary > systems for this sort of thing (e.g., CCC), but we need to migrate such > processes outside the firewall. That'll be a lot easier if we can simply > leverage the bug tracker. > > - Mark A slight variation on that is "variable approval workflows" since the approval process changes throughout the life of the release. -- Jon From gnu_andrew at member.fsf.org Wed Mar 16 08:57:32 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 16 Mar 2011 15:57:32 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <20110316045920.F25257F7@eggemoggin.niobe.net> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> Message-ID: On 16 March 2011 04:59, wrote: > 2011/3/3 14:03 -0800, roger.lewis at oracle.com: >> A draft of the OpenJDK Bug Tracking Project is now available. ?For further >> information please see: >> http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html > > Thanks Roger. ?Here are some comments, and some additional suggested > requirements. > >> * Web Services or REST APIs for querying and updating bugs > > Mark Wielaard asked whether the WS/REST API should support creating new > bugs. ?I'd go further and say that it should support every operation > that's supported by the system's usual user interfaces. ?It should be > possible, in principle, to create an alternative UI that can completely > replace the system's native UI. ?This ensures maximum flexibility for > related programmatic systems ("boundary systems"), prevents us from > being locked-in to a (potentially) stale UI, and allows for creative > experimentation with alternative UIs (e.g., based upon Java FX). > > I also think we should have a strong preference for REST over WS-style > web APIs. ?The big WS-* standards failed. ?Let's avoid them. > >> * Supports a rich query language >> * Web client >> * Email notification for new bugs >> * Email notification for bug state changes > > E-mail notification for content updates (e.g., new comments or updated > evaluations) should also be supported. > > I agree with Mark Wielaard that it would be nice if bugs could be updated > via e-mail, but I worry about the problem of authenticating such updates. > >> * Able to look up old bug Ids >> * Available 24 hours a day, 7 days a week (not including maintenance and downtime) >> * Provides the ability to vote and comment on a bug > > As we've discussed in person, it's not clear to me that voting by > arbitrary users is something that needs to be supported natively. ?If > we're going to continue the Bug Parade voting tradition then that could > be implemented in a separate boundary system. > > As to some of Mark Wielaard's other suggestions: > > 2011/3/4 10:38 -0800, Mark Wielaard : >> Nice to have things might be: >> >> - Version tracking of issues, related to openjdk releases/branches. >> ? - Known working/failing versions. >> ? - Milestones? >> - Attaching files, patches, etc. > > This is absolutely critical. > >> - Inter bug tracking (so you can reference bugs from other project, >> ? downstream/upstream, etc.), with possible notification when such >> ? a referenced bug gets updated and/or updating other bug trackers >> ? when this bug report gets updated. > > That'd be nice, but I don't know of any system that actually implements > this. > >> - dependencies between bugs, so you can create tracking bugs for >> ? some feature, which is only completed when all bugs that it >> ? depend on are resolved. > > I think this is critical, not only for feature-tracking bugs but also for > distinct, interdependent bugs. ?It always annoyed me that Sun's internal > bug trackers never supported dependences. ?Ideally one should be able to > express such dependences from either direction, i.e., "this bug blocks > that one", or "that bug blogs this one". > >> ? - Bonus points for having nice dependency graphs. >> - mercurial integration, so that when a patch that references a >> ? bug is committed to some tree it can add a note to the bug report. > > Yep. > >> - bug group category or user watching, so one can follow work >> ? (useful when you take over someone work for a while, or need to >> ? ?do Q/A for some category of bugs). >> - have some way to mark/show frequently occurring bugs, so you >> ? can easily reference known issues with a simple URL. >> - integration with patch viewer/review process/mercurial >> ? so patches attached to bugs can easily be reviewed, changed >> ? and/or committed. > > All of these would be nice to have, but I don't see them as critical. > > Here a few additional requirements which I haven't yet seen anyone raise. > Some of these are taken or adapted from the OpenSolaris bug-tracking > requirements document [1]. > > ?- Integration with the OpenJDK people database. ?The bug tracker should > ? ?provide a programmatic interface for adding and modifying users, so > ? ?that when a contributor is added to the OpenJDK people database the > ? ?system can automatically grant appropriate rights in the bug tracker, > ? ?creating a new bug-tracker account if necessary or tying to an > ? ?existing account. ?The bug tracker must also support whatever > ? ?single-sign-on solution is eventually implemented for OpenJDK. > > ?- It must be possible to hide certain classes of bugs (e.g., security > ? ?bugs) from all but a select few users or groups of users. > > ?- Extensibility via programmatic state-change hooks or a similar > ? ?mechanism is highly desirable. ?Ideally such hooks should be able to > ? ?veto state changes. ?Many of the boundary-system hacks we've built > ? ?over the years against Sun's internal bug trackers solved problems > ? ?that could've been more easily solved with such hooks. > > ?- A stable export format for bug reports (e.g., XML using a defined DTD > ? ?or schema), for easy digestion and repurposing by boundary systems. > > ?- Both hierarchical (product/category/subcategory) and non-hierarchical > ? ?(i.e., keyword or tag) bug classification. > > ?- Unicode should be fully supported in all fields of a bug report, in > ? ?the query language/interface, and in the WS/REST API. > > Finally, I'm surprised that no one has mentioned the "CR/sub-CR" feature > of Sun's current internal system. ?It's a bit clunky, but it makes it > relatively straightforward to track related-but-distinct fixes to the > same bug in different lines of code. > > - Mark > > > [1] http://src.opensolaris.org/source/xref/website/spec/dts-requirements/d-dts-requirements.txt > You seem to have omitted the licensing of the bug system. It should be Free Software, in line with the rest of OpenJDK. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From philip.race at oracle.com Wed Mar 16 09:11:56 2011 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 Mar 2011 09:11:56 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> Message-ID: <4D80E14C.7030801@oracle.com> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: > > You seem to have omitted the licensing of the bug system. It should > be Free Software, in line with the rest of OpenJDK. This is over-ridden by a need to meet the real requirements. The licensing is not a real requirement. Its a preference. If some non-free software fits the needs better then so be it. And If Oracle is willing to foot the bill that's fine by me. -phil. From gnu_andrew at member.fsf.org Wed Mar 16 11:45:09 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 16 Mar 2011 18:45:09 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D80E14C.7030801@oracle.com> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> Message-ID: On 16 March 2011 16:11, Phil Race wrote: > On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >> >> You seem to have omitted the licensing of the bug system. ?It should >> be Free Software, in line with the rest of OpenJDK. > > This is over-ridden by a need to meet the real requirements. The licensing > is not > a real requirement. Its a preference. If some non-free software fits the > needs better > then so be it. And If Oracle is willing to foot the bill that's fine by me. > > -phil. > Nobody said anything about cost. I'm talking about Free as in Freedom. For me, this is the overridding factor. If we're just going to replace one proprietary bug database with another, we may as well just stick with the one we already have. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From philip.race at oracle.com Wed Mar 16 12:14:52 2011 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 Mar 2011 12:14:52 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> Message-ID: <4D810C2C.1010703@oracle.com> On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: > On 16 March 2011 16:11, Phil Race wrote: >> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>> You seem to have omitted the licensing of the bug system. It should >>> be Free Software, in line with the rest of OpenJDK. >> This is over-ridden by a need to meet the real requirements. The licensing >> is not >> a real requirement. Its a preference. If some non-free software fits the >> needs better >> then so be it. And If Oracle is willing to foot the bill that's fine by me. >> >> -phil. >> > Nobody said anything about cost. I'm talking about Free as in Freedom. > > For me, this is the overridding factor. If we're just going to > replace one proprietary bug database with another, we may as well just > stick with the one we already have. I completely understand what you mean. Its just that its not the overriding factor. I don't see any necessary connection between being an open source project and using an open source tool chain. And it doesn't matter whether the software is free or not. The administration of it will doubtless not be "free" in any sense. The one that's used now isn't a problem because its not open source. Its a problem because its not accessible. -phil. From kelly.ohair at oracle.com Wed Mar 16 13:19:57 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 16 Mar 2011 13:19:57 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D810C2C.1010703@oracle.com> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> <4D810C2C.1010703@oracle.com> Message-ID: On Mar 16, 2011, at 12:14 PM, Phil Race wrote: > On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: >> On 16 March 2011 16:11, Phil Race wrote: >>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>>> You seem to have omitted the licensing of the bug system. It should >>>> be Free Software, in line with the rest of OpenJDK. >>> This is over-ridden by a need to meet the real requirements. The licensing >>> is not >>> a real requirement. Its a preference. If some non-free software fits the >>> needs better >>> then so be it. And If Oracle is willing to foot the bill that's fine by me. >>> >>> -phil. >>> >> Nobody said anything about cost. I'm talking about Free as in Freedom. >> >> For me, this is the overridding factor. If we're just going to >> replace one proprietary bug database with another, we may as well just >> stick with the one we already have. > > I completely understand what you mean. Its just that its not the overriding factor. > I don't see any necessary connection between being an open source project and > using an open source tool chain. > And it doesn't matter whether the software is free or not. The administration of > it will doubtless not be "free" in any sense. > The one that's used now isn't a problem because its not open source. Its a problem > because its not accessible. > > -phil I kind of agree with Phil here. Openly accessible is the critical issue here. I'm concerned that if we limit ourselves to just open source bug tracking tools, we have narrowed down the selections a bit too much. I don't really care which one gets picked myself, I just want it done. I also don't believe in the Tooth Fairy, and am not expecting all these great features to be available on day 1, no matter which tool is picked, all this will take some time. I'm after the "openly accessible" part, and as soon as possible. Although I have to confess that years ago I tried to get my children to believe in the ToeNail Fairy, unfortunately they knew me too well and I failed. :^( -kto > From gnu_andrew at member.fsf.org Wed Mar 16 14:39:43 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 16 Mar 2011 21:39:43 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D810C2C.1010703@oracle.com> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> <4D810C2C.1010703@oracle.com> Message-ID: On 16 March 2011 19:14, Phil Race wrote: > On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: >> >> On 16 March 2011 16:11, Phil Race ?wrote: >>> >>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>>> >>>> You seem to have omitted the licensing of the bug system. ?It should >>>> be Free Software, in line with the rest of OpenJDK. >>> >>> This is over-ridden by a need to meet the real requirements. The >>> licensing >>> is not >>> a real requirement. Its a preference. If some non-free software fits the >>> needs better >>> then so be it. And If Oracle is willing to foot the bill that's fine by >>> me. >>> >>> -phil. >>> >> Nobody said anything about cost. ?I'm talking about Free as in Freedom. >> >> For me, this is the overridding factor. ?If we're just going to >> replace one proprietary bug database with another, we may as well just >> stick with the one we already have. > > I completely understand what you mean. Funny, it doesn't sound like it. > Its just that its not the overriding > factor. > I don't see any necessary connection between being an open source project > and > using an open source tool chain. Clearly this seems to have been true of most people at Sun, leading to OpenJDK being released in the state it was and IcedTea having to be created to make it buildable. > And it doesn't matter whether the software is free or not. The > administration of > it will doubtless not be "free" in any sense. > The one that's used now isn't a problem because its not open source. Its a > problem > because its not accessible. > It matters to me and other people too no doubt. It's not just about the source code being available. Having transparency and working in the open has an effect on development which leads to a different product than one which would be developed in a proprietary setting. We may not need to be able to build our own copy of the database but we do need to be able to trust the software that's running on the server and that's impossible with a proprietary solution. You can apply all these comments to jcheck too, as I've mentioned on many an occasion. You already have a Bugzilla instance set up. Why not just use it? > -phil. > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From swingler at apple.com Wed Mar 16 15:14:01 2011 From: swingler at apple.com (Mike Swingler) Date: Wed, 16 Mar 2011 15:14:01 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> <4D810C2C.1010703@oracle.com> Message-ID: <0D9C8BE9-C4AB-4874-9122-4500151C9225@apple.com> On Mar 16, 2011, at 2:39 PM, Dr Andrew John Hughes wrote: > On 16 March 2011 19:14, Phil Race wrote: > >> On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: >>> >>> On 16 March 2011 16:11, Phil Race wrote: >>>> >>>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>>> >>>>> You seem to have omitted the licensing of the bug system. It should >>>>> be Free Software, in line with the rest of OpenJDK. >>>> >>>> This is over-ridden by a need to meet the real requirements. The >>>> licensing >>>> is not >>>> a real requirement. Its a preference. If some non-free software fits the >>>> needs better >>>> then so be it. And If Oracle is willing to foot the bill that's fine by >>>> me. >>>> >>>> -phil. >>> >>> Nobody said anything about cost. I'm talking about Free as in Freedom. >>> >>> For me, this is the overridding factor. If we're just going to >>> replace one proprietary bug database with another, we may as well just >>> stick with the one we already have. >> >> I completely understand what you mean. > > Funny, it doesn't sound like it. We may understand your concerns, and simply disagree. The difference is between Free Software being it's own first order good, or the actual creation of the OpenJDK product itself. >> Its just that its not the overriding >> factor. >> I don't see any necessary connection between being an open source project >> and >> using an open source tool chain. > > Clearly this seems to have been true of most people at Sun, leading to > OpenJDK being released in the state it was and IcedTea having to be > created to make it buildable. > >> And it doesn't matter whether the software is free or not. The >> administration of >> it will doubtless not be "free" in any sense. >> The one that's used now isn't a problem because its not open source. Its a >> problem >> because its not accessible. > > It matters to me and other people too no doubt. It's not just about > the source code being available. Having transparency and working in > the open has an effect on development which leads to a different > product than one which would be developed in a proprietary setting. > We may not need to be able to build our own copy of the database but > we do need to be able to trust the software that's running on the > server and that's impossible with a proprietary solution. You can > apply all these comments to jcheck too, as I've mentioned on many an > occasion. >From an end-users perspective, there are proprietary bug systems which may more useable than their open-source counterparts. Trust in the software to perform it's functions may be possible given access to it's source, but for most practical purposes, is not actually verifiable except by domain experts. I agree that the license of the software is a secondary concern compared to the ability of the software to perform it's required functions. > You already have a Bugzilla instance set up. Why not just use it? I am curious about this as well. Does it simply not scale when confronted with the sheer volume of bugs in the existing Sun database? Regards, Mike Swingler Java Engineering Apple Inc. From spoole at linux.vnet.ibm.com Fri Mar 18 01:28:15 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Fri, 18 Mar 2011 08:28:15 +0000 Subject: OpenJDK Bug Tracking Project In-Reply-To: <0D9C8BE9-C4AB-4874-9122-4500151C9225@apple.com> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> <4D810C2C.1010703@oracle.com> <0D9C8BE9-C4AB-4874-9122-4500151C9225@apple.com> Message-ID: <4D83179F.9050902@linux.vnet.ibm.com> On 16/03/11 22:14, Mike Swingler wrote: > On Mar 16, 2011, at 2:39 PM, Dr Andrew John Hughes wrote: > >> On 16 March 2011 19:14, Phil Race wrote: >> >>> On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: >>>> On 16 March 2011 16:11, Phil Race wrote: >>>>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>>>> >>>>>> You seem to have omitted the licensing of the bug system. It should >>>>>> be Free Software, in line with the rest of OpenJDK. >>>>> This is over-ridden by a need to meet the real requirements. The >>>>> licensing >>>>> is not >>>>> a real requirement. Its a preference. If some non-free software fits the >>>>> needs better >>>>> then so be it. And If Oracle is willing to foot the bill that's fine by >>>>> me. >>>>> >>>>> -phil. >>>> Nobody said anything about cost. I'm talking about Free as in Freedom. >>>> >>>> For me, this is the overridding factor. If we're just going to >>>> replace one proprietary bug database with another, we may as well just >>>> stick with the one we already have. >>> I completely understand what you mean. >> Funny, it doesn't sound like it. > We may understand your concerns, and simply disagree. > > The difference is between Free Software being it's own first order good, or the actual creation of the OpenJDK product itself. > >>> Its just that its not the overriding >>> factor. >>> I don't see any necessary connection between being an open source project >>> and >>> using an open source tool chain. >> Clearly this seems to have been true of most people at Sun, leading to >> OpenJDK being released in the state it was and IcedTea having to be >> created to make it buildable. >> >>> And it doesn't matter whether the software is free or not. The >>> administration of >>> it will doubtless not be "free" in any sense. >>> The one that's used now isn't a problem because its not open source. Its a >>> problem >>> because its not accessible. >> It matters to me and other people too no doubt. It's not just about >> the source code being available. Having transparency and working in >> the open has an effect on development which leads to a different >> product than one which would be developed in a proprietary setting. >> We may not need to be able to build our own copy of the database but >> we do need to be able to trust the software that's running on the >> server and that's impossible with a proprietary solution. You can >> apply all these comments to jcheck too, as I've mentioned on many an >> occasion. > > From an end-users perspective, there are proprietary bug systems which may more useable than their open-source counterparts. Trust in the software to perform it's functions may be possible given access to it's source, but for most practical purposes, is not actually verifiable except by domain experts. > > I agree that the license of the software is a secondary concern compared to the ability of the software to perform it's required functions. > >> You already have a Bugzilla instance set up. Why not just use it? > I am curious about this as well. Does it simply not scale when confronted with the sheer volume of bugs in the existing Sun database? Thats a good point and question - how many existing bugs are we talking about and what's the average arrival rate? > Regards, > Mike Swingler > Java Engineering > Apple Inc. > From roger.lewis at oracle.com Fri Mar 18 11:35:59 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Fri, 18 Mar 2011 11:35:59 -0700 Subject: OpenJDK Bug Tracking Project In-Reply-To: <4D83179F.9050902@linux.vnet.ibm.com> References: <4D701047.5030906@oracle.com> <20110316045920.F25257F7@eggemoggin.niobe.net> <4D80E14C.7030801@oracle.com> <4D810C2C.1010703@oracle.com> <0D9C8BE9-C4AB-4874-9122-4500151C9225@apple.com> <4D83179F.9050902@linux.vnet.ibm.com> Message-ID: <4D83A60F.5020604@oracle.com> On 3/18/11 1:28 AM, Steve Poole wrote: > On 16/03/11 22:14, Mike Swingler wrote: >> On Mar 16, 2011, at 2:39 PM, Dr Andrew John Hughes wrote: >> >>> On 16 March 2011 19:14, Phil Race wrote: >>> >>>> On 3/16/2011 11:45 AM, Dr Andrew John Hughes wrote: >>>>> On 16 March 2011 16:11, Phil Race wrote: >>>>>> On 3/16/2011 8:57 AM, Dr Andrew John Hughes wrote: >>>>>> >>>>>>> You seem to have omitted the licensing of the bug system. It >>>>>>> should >>>>>>> be Free Software, in line with the rest of OpenJDK. >>>>>> This is over-ridden by a need to meet the real requirements. The >>>>>> licensing >>>>>> is not >>>>>> a real requirement. Its a preference. If some non-free software >>>>>> fits the >>>>>> needs better >>>>>> then so be it. And If Oracle is willing to foot the bill that's >>>>>> fine by >>>>>> me. >>>>>> >>>>>> -phil. >>>>> Nobody said anything about cost. I'm talking about Free as in >>>>> Freedom. >>>>> >>>>> For me, this is the overridding factor. If we're just going to >>>>> replace one proprietary bug database with another, we may as well >>>>> just >>>>> stick with the one we already have. >>>> I completely understand what you mean. >>> Funny, it doesn't sound like it. >> We may understand your concerns, and simply disagree. >> >> The difference is between Free Software being it's own first order >> good, or the actual creation of the OpenJDK product itself. >> >>>> Its just that its not the overriding >>>> factor. >>>> I don't see any necessary connection between being an open source >>>> project >>>> and >>>> using an open source tool chain. >>> Clearly this seems to have been true of most people at Sun, leading to >>> OpenJDK being released in the state it was and IcedTea having to be >>> created to make it buildable. >>> >>>> And it doesn't matter whether the software is free or not. The >>>> administration of >>>> it will doubtless not be "free" in any sense. >>>> The one that's used now isn't a problem because its not open >>>> source. Its a >>>> problem >>>> because its not accessible. >>> It matters to me and other people too no doubt. It's not just about >>> the source code being available. Having transparency and working in >>> the open has an effect on development which leads to a different >>> product than one which would be developed in a proprietary setting. >>> We may not need to be able to build our own copy of the database but >>> we do need to be able to trust the software that's running on the >>> server and that's impossible with a proprietary solution. You can >>> apply all these comments to jcheck too, as I've mentioned on many an >>> occasion. >> > From an end-users perspective, there are proprietary bug systems >> which may more useable than their open-source counterparts. Trust in >> the software to perform it's functions may be possible given access >> to it's source, but for most practical purposes, is not actually >> verifiable except by domain experts. >> >> I agree that the license of the software is a secondary concern >> compared to the ability of the software to perform it's required >> functions. >> >>> You already have a Bugzilla instance set up. Why not just use it? >> I am curious about this as well. Does it simply not scale when >> confronted with the sheer volume of bugs in the existing Sun database? > Thats a good point and question - how many existing bugs are we > talking about and what's the average arrival rate? Indeed a good question. As a note, I do not believe that we have ever really shared some of these numbers publicly before. I can't say that I aware of any specific reason that these numbers were not talked about. Today, there are approximately 120,000 bugs in Bugtraq (our bug tracking system). We have seen over the last few years that the number of bugs is growing at about 7,000 bugs per year. These come from many internal, external sources. As it has been stated we want to move all of these 120,000 bugs into the new system. The feeling is that there is great historical knowledge that these bugs provide and loosing them would be a shame. Now for some bigger numbers and a longer explanation..... There is a second system of bug reports, or as we have called them, Incidents. There is some overlap in that 7,000 per year number. These are the reports are come in though bugs.sun.com. Historically these had gone into a review system, were some were added to Bugtraq, many, many, many were found to be duplicates (in those cases some of the data was added to Bugtraq) and others were not reproducible and were never added to Bugtraq. [This could be an entirely separate thread I am sure.] Over the last 2 years, it has been a gradual transition, the Incidents have been making their way directly into an area within Bugtraq where they can be reviewed as well as be seeing within a day or two on bugs.sun.com. Some of are calling this a 'triage area'. The intent is to have these type of reports to go into the new bug tracking system and likely continue to go into a triage area where they can be reviewed. One could ask why they need to go into a triage area...... The answer is that the numbers are a bit staggering, and many of the reports are not complete or duplicates. We currently have over 200,00 Incidents and new Incidents are currently submitted at the rate of 18,000 per year. We do not plan on moving over the 200,000 Incidents into the new system. Given those historic numbers, planning for an unknown future number of bugs to be added, and building a system that be used for about 10 years, we believe that the system should be able to scale up to 1 Million bugs. -Roger >> Regards, >> Mike Swingler >> Java Engineering >> Apple Inc. >> > From mark.reinhold at oracle.com Fri Mar 18 13:25:51 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 18 Mar 2011 13:25:51 -0700 Subject: A simple request: Please trim quoted text Message-ID: <20110318202551.E39AC7CA@eggemoggin.niobe.net> It'd be wonderful if people could please stop quoting every single line of the messages to which they reply. The bug-tracking thread is becoming increasingly difficult to read. We all shouldn't have to page through multiple screens of text just to read a three-line reply. Please: Just quote what you need to, or don't quote at all. Thanks, - Mark From mark at klomp.org Wed Mar 23 01:41:06 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 23 Mar 2011 09:41:06 +0100 Subject: Moderated distro-pkg-dev message disappeared? In-Reply-To: References: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> <60679.80.101.103.228.1299433589.squirrel@gnu.wildebeest.org> Message-ID: <1300869666.3244.2.camel@springer.wildebeest.org> Hi Tim, On Sun, 2011-03-06 at 10:20 -0800, Tim Bell wrote: > >> That was the SPAM killer cron job: > >> > >> Discarded held msg #1442 for list distro-pkg-dev > > > > What made it decide to discard it? I can tweak the script that > > sends the commit message if necessary. > > The reason the message was held in the first place was that user 'mark > at icedtea.classpath.org' was not subscribed to distro-pkg-dev. This > happens when the mercurial username != the subscriber username. When > I approved the held message this time around, I ticked the 'always > accept email from this user' box, so future messages won't be held. > > The cron SPAM filter only looks at held messages. What triggered it > was the word 'officially' in the held message. I removed that word > from the regex as it is too general. Other strings such as 'C L I C K > H E R E' are excellent predictors for SPAM. Got another one that silently disappeared: List: distro-pkg-dev at openjdk.java.net From: jvanek at redhat.com Subject: reviewer needed: Generating about, authors... from NEWS, AUTHORS... Any idea why? > > I am not afraid of the command line :) > > Just don't know how to get at it. > > Unfortunately, that is not mine to give out. Check with Mark Reinhold. I added Mark to the CC. Thanks, Mark From tim.bell at gmail.com Wed Mar 23 17:45:36 2011 From: tim.bell at gmail.com (Tim Bell) Date: Wed, 23 Mar 2011 17:45:36 -0700 Subject: Moderated distro-pkg-dev message disappeared? In-Reply-To: <1300869666.3244.2.camel@springer.wildebeest.org> References: <37177.80.101.103.228.1299426277.squirrel@gnu.wildebeest.org> <60679.80.101.103.228.1299433589.squirrel@gnu.wildebeest.org> <1300869666.3244.2.camel@springer.wildebeest.org> Message-ID: Hi Mark > Got another one that silently disappeared: > > List: ? ?distro-pkg-dev at openjdk.java.net > From: ? ?jvanek at redhat.com > Subject: reviewer needed: Generating about, authors... from NEWS, > AUTHORS... > > Any idea why? Looking in ~mailman/logs/vette shows: Mar 22 09:12:31 2011 (4537) distro-pkg-dev post from jvanek at redhat.com held, message-id=<4D88C980.4040501 at redhat.com>: Message body is too big: 557559 bytes with a limit of 350 KB a few moments later: Mar 22 09:18:04 2011 (15696) distro-pkg-dev: Discarded posting: From: jvanek at redhat.com Subject: reviewer needed: Generating about, authors... from NEWS, AUTHORS.... The 'drop spam' job runs at 3,18,33,48 minutes past the hour. I will re-queue the email in a moment. BTW: I just raised the message body limit to.750KB for distro-pkg-dev, so the message should go right through. Tim >> > I am not afraid of the command line :) >> > Just don't know how to get at it. >> >> Unfortunately, that is not mine to give out. ?Check with Mark Reinhold. > > I added Mark to the CC. > > Thanks, > > Mark > > From roger.lewis at oracle.com Tue Mar 29 21:28:46 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Tue, 29 Mar 2011 21:28:46 -0700 Subject: OpenJDK Bug Tracking Project Requirements, consolidated list Message-ID: <4D92B17E.8000308@oracle.com> Hello, Thank you for the feedback so far. The requirements that were suggested have been added/consolidated to the list that we will be using to help determine the our choice of defect tracking system[1][2]. This list combines requirements from both the standpoint of OpenJDK developers as well as the community as a whole and internal needs from our quality, sustaining and release management groups. What we want to start to do now is to map the requirements to candidate systems; the two options we are looking at are Bugzilla[3] and JIRA[4]. We are starting with these two as from our initial discussions they are the most common choices for open source projects. From our analysis so far either system would meet the majority of our needs but we would like to get input from other projects that are using these systems, and will also be talking over the next couple of week to consultants with experience setting up these systems. A key driver for us is the integration of the bug tracking system into the overall OpenJDK infrastructure (code review tool, bug approvals etc.) and how well the system will enable us to build upon the bugs.sun.com functionality we have had in place since the early releases of Java. We believe that a key element of Java's success has been the straightforward way in which the community has been able to provide feedback/bugs as this has allowed us to provide a robust implementation of Java. From the list of requirements you will see a number of items which require 'customization' as they are not available out-of-the-box from either system. We are writing up more details around these in order that we can better scope the necessary work and will send that out as we finish it. We need to drive to a decision as we want to make sure that the system is in place around the time that JDK 7 ships with early instances available as JDK 8 development starts up, given this we have set the end of April as the deadline for the decision. Please continue to provide feedback and ideas, Roger [1] http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.ods [2] http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.pdf [3]http://www.bugzilla.org/ [4]http://atlassian.com/JIRA From gnu_andrew at member.fsf.org Wed Mar 30 05:27:47 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 13:27:47 +0100 Subject: OpenJDK Bug Tracking Project Requirements, consolidated list In-Reply-To: <4D92B17E.8000308@oracle.com> References: <4D92B17E.8000308@oracle.com> Message-ID: On 30 March 2011 05:28, Roger Lewis wrote: > Hello, > > What we want to start to do now is to map the requirements to candidate > systems; the two options we are looking at are Bugzilla[3] and JIRA[4]. We > are starting with these two as from our initial discussions they are the > most common choices for open source projects. From our analysis so far > either system would meet the majority of our needs but we would like to get > input from other projects that are using these systems, and will also be > talking over the next couple of week to consultants with experience setting > up these systems. > > > If the requirements are met by both, then the obvious choice is Bugzilla, given you already have it setup on bugs.openjdk.java.net and it's Free Software. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From Ulf.Zibis at gmx.de Wed Mar 30 05:40:30 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 30 Mar 2011 14:40:30 +0200 Subject: OpenJDK Bug Tracking Project Requirements, consolidated list In-Reply-To: <4D92B17E.8000308@oracle.com> References: <4D92B17E.8000308@oracle.com> Message-ID: <4D9324BE.6000408@gmx.de> Hi, I have problems to read the pdf via the Adobe plugin in Firefox. Could you please add a html version? -Ulf Am 30.03.2011 06:28, schrieb Roger Lewis: > Hello, > > Thank you for the feedback so far. The requirements that were suggested have been > added/consolidated to the list that we will be using to help determine the our choice of defect > tracking system[1][2]. This list combines requirements from both the standpoint of OpenJDK > developers as well as the community as a whole and internal needs from our quality, sustaining and > release management groups. > > What we want to start to do now is to map the requirements to candidate systems; the two options > we are looking at are Bugzilla[3] and JIRA[4]. We are starting with these two as from our initial > discussions they are the most common choices for open source projects. From our analysis so far > either system would meet the majority of our needs but we would like to get input from other > projects that are using these systems, and will also be talking over the next couple of week to > consultants with experience setting up these systems. > > A key driver for us is the integration of the bug tracking system into the overall OpenJDK > infrastructure (code review tool, bug approvals etc.) and how well the system will enable us to > build upon the bugs.sun.com functionality we have had in place since the early releases of Java. > We believe that a key element of Java's success has been the straightforward way in which the > community has been able to provide feedback/bugs as this has allowed us to provide a robust > implementation of Java. > > From the list of requirements you will see a number of items which require 'customization' as they > are not available out-of-the-box from either system. We are writing up more details around these > in order that we can better scope the necessary work and will send that out as we finish it. > > We need to drive to a decision as we want to make sure that the system is in place around the time > that JDK 7 ships with early instances available as JDK 8 development starts up, given this we have > set the end of April as the deadline for the decision. Please continue to provide feedback and > ideas, > > Roger > > [1] http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.ods > [2] http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.pdf > [3]http://www.bugzilla.org/ > [4]http://atlassian.com/JIRA > > From roger.lewis at oracle.com Wed Mar 30 12:00:51 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Wed, 30 Mar 2011 12:00:51 -0700 Subject: OpenJDK Bug Tracking Project Requirements, consolidated list In-Reply-To: <4D9324BE.6000408@gmx.de> References: <4D92B17E.8000308@oracle.com> <4D9324BE.6000408@gmx.de> Message-ID: <4D937DE3.6070608@oracle.com> I have added an HTML file. http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.html Thanks, Roger On 3/30/11 5:40 AM, Ulf Zibis wrote: > Hi, > > I have problems to read the pdf via the Adobe plugin in Firefox. Could > you please add a html version? > > -Ulf > > > > Am 30.03.2011 06:28, schrieb Roger Lewis: >> Hello, >> >> Thank you for the feedback so far. The requirements that were >> suggested have been added/consolidated to the list that we will be >> using to help determine the our choice of defect tracking >> system[1][2]. This list combines requirements from both the >> standpoint of OpenJDK developers as well as the community as a whole >> and internal needs from our quality, sustaining and release >> management groups. >> >> What we want to start to do now is to map the requirements to >> candidate systems; the two options we are looking at are Bugzilla[3] >> and JIRA[4]. We are starting with these two as from our initial >> discussions they are the most common choices for open source >> projects. From our analysis so far either system would meet the >> majority of our needs but we would like to get input from other >> projects that are using these systems, and will also be talking over >> the next couple of week to consultants with experience setting up >> these systems. >> >> A key driver for us is the integration of the bug tracking system >> into the overall OpenJDK infrastructure (code review tool, bug >> approvals etc.) and how well the system will enable us to build upon >> the bugs.sun.com functionality we have had in place since the early >> releases of Java. We believe that a key element of Java's success >> has been the straightforward way in which the community has been >> able to provide feedback/bugs as this has allowed us to provide a >> robust implementation of Java. >> >> From the list of requirements you will see a number of items which >> require 'customization' as they are not available out-of-the-box from >> either system. We are writing up more details around these in order >> that we can better scope the necessary work and will send that out as >> we finish it. >> >> We need to drive to a decision as we want to make sure that the >> system is in place around the time that JDK 7 ships with early >> instances available as JDK 8 development starts up, given this we >> have set the end of April as the deadline for the decision. Please >> continue to provide feedback and ideas, >> >> Roger >> >> [1] >> http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.ods >> [2] >> http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.pdf >> [3]http://www.bugzilla.org/ >> [4]http://atlassian.com/JIRA >> >> From roger.lewis at oracle.com Wed Mar 30 14:54:36 2011 From: roger.lewis at oracle.com (Roger Lewis) Date: Wed, 30 Mar 2011 14:54:36 -0700 Subject: OpenJDK Bug Tracking Project Requirements, consolidated list In-Reply-To: <4D937DE3.6070608@oracle.com> References: <4D92B17E.8000308@oracle.com> <4D9324BE.6000408@gmx.de> <4D937DE3.6070608@oracle.com> Message-ID: <4D93A69C.5070600@oracle.com> It was pointed out that the HTML page could not display correctly in FF4.0 and in IE. I have regenerated the file and tested it on a number of OS/Browser combinations and it has loaded correctly. -Roger On 3/30/11 12:00 PM, Roger Lewis wrote: > I have added an HTML file. > http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.html > > > Thanks, > Roger > > > On 3/30/11 5:40 AM, Ulf Zibis wrote: >> Hi, >> >> I have problems to read the pdf via the Adobe plugin in Firefox. >> Could you please add a html version? >> >> -Ulf >> >> >> >> Am 30.03.2011 06:28, schrieb Roger Lewis: >>> Hello, >>> >>> Thank you for the feedback so far. The requirements that were >>> suggested have been added/consolidated to the list that we will be >>> using to help determine the our choice of defect tracking >>> system[1][2]. This list combines requirements from both the >>> standpoint of OpenJDK developers as well as the community as a whole >>> and internal needs from our quality, sustaining and release >>> management groups. >>> >>> What we want to start to do now is to map the requirements to >>> candidate systems; the two options we are looking at are Bugzilla[3] >>> and JIRA[4]. We are starting with these two as from our initial >>> discussions they are the most common choices for open source >>> projects. From our analysis so far either system would meet the >>> majority of our needs but we would like to get input from other >>> projects that are using these systems, and will also be talking over >>> the next couple of week to consultants with experience setting up >>> these systems. >>> >>> A key driver for us is the integration of the bug tracking system >>> into the overall OpenJDK infrastructure (code review tool, bug >>> approvals etc.) and how well the system will enable us to build upon >>> the bugs.sun.com functionality we have had in place since the early >>> releases of Java. We believe that a key element of Java's success >>> has been the straightforward way in which the community has been >>> able to provide feedback/bugs as this has allowed us to provide a >>> robust implementation of Java. >>> >>> From the list of requirements you will see a number of items which >>> require 'customization' as they are not available out-of-the-box >>> from either system. We are writing up more details around these in >>> order that we can better scope the necessary work and will send that >>> out as we finish it. >>> >>> We need to drive to a decision as we want to make sure that the >>> system is in place around the time that JDK 7 ships with early >>> instances available as JDK 8 development starts up, given this we >>> have set the end of April as the deadline for the decision. Please >>> continue to provide feedback and ideas, >>> >>> Roger >>> >>> [1] >>> http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.ods >>> [2] >>> http://cr.openjdk.java.net/~rlewis/BugTracking/requirements/SystemXv1.pdf >>> [3]http://www.bugzilla.org/ >>> [4]http://atlassian.com/JIRA >>> >>>