From mark.reinhold at oracle.com Sat Jun 4 22:31:20 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 04 Jun 2011 22:31:20 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: mohan.pakkurti@oracle.com; Tue, 24 May 2011 21:48:30 +0200; Message-ID: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> 2011/5/24 12:48 -0700, mohan.pakkurti at oracle.com: > As you know from earlier discussions, we have been evaluating Bugzilla > and JIRA for bug management for OpenJDK. > > I have posted the latest comparison notes here: > > http://cr.openjdk.java.net/~mo/openjdk/bugsystem/BugzillaJIRAComparison.pdf > > It would be great to hear your comments on this. Thanks for pulling all this information together. Here are some comments and questions about it. - Implementation language -- You list Bugzilla as being at a disadvantage here because it's written in Perl. I don't think the implementation language is all that important. Regardless of which system we choose I doubt we're going to customize it much, since customization inevitably increases the cost of doing the next version upgrade. - Required environment -- Why is an Apache+CGI/mod_perl environment worse than standalone, or WAR/EAR? (Bugzilla runs just fine, by the way, under other web servers such as lighttpd.) - Database -- Why is it a major concern that Bugzilla doesn't support the Oracle database? If MySQL is good enough for bugs.mozilla.org then it's almost certainly good enough for us. - Web-service API -- A critical sub-question here is whether the API exposes all of the data and every action that's available through the browser interface. It must be possible, in principle, to do two things: (1) Extract all of the data in order to mirror the bug database on another system, and (2) Create an alternative client interface that has all the functionality of the browser interface. To what degree do Bugzilla and JIRA support these goals? - CLI -- For Bugzilla there's PyBugz [1], an actively-maintained Python interface to Bugzilla which includes a CLI. - Identity -- I don't understand why Bugzilla is listed as requiring third-party identity plugins. Bugzilla has full support for LDAP, a recognized industry standard. Is that not sufficient? - Access permissions -- Why do we need field-level access control? What are the use cases for that? - Query language, Reports, Actions, Notifications -- The color codes of the headings at the top of these sections indicate that Bugzilla has "minor concerns and deficiencies", but you don't say what they are. - Preservation of bug ids -- You say that Bugzilla can retain bug ids, and that JIRA might be able to retain bug ids ("but needs work") and in any case will force a project prefix ("JAVA-"). I consider it a hard requirement that we be able to retain existing bug ids -- not just have special fields that cross-link to them, but actually retain them. These ids have been used in so many places for so many years that not retaining them is going to be a significant ease-of-use issue. I also think JIRA's mandatory bug-id project prefix is, well, ridiculous. Why must we type "JAVA-" (or "JDK-", or whatever) in front of every single bug number? What value does that add? The prefix convention may well be useful in a large community with many unrelated projects, but that's not what OpenJDK is. - Workflows -- Why is supporting multiple workflows a hard requirement? What are the use cases? Are there ways to support those use cases by means other than separate workflows? - Integration -- I don't understand why Bugzilla is listed as being at such a disadvantage here. Can you please elaborate? Overall, I have to agree with previous comments to the effect that this analysis seems, so far, to be somewhat biased in favor of JIRA. I look forward to seeing answers to the questions I've raised above so that we can make as objective a decision as possible. For the record, I'm not a huge fan of either of these systems. In the end I think the most critical requirements are an underlying data model that meets our needs together with a complete and open web API so that alternative clients and boundary systems can be constructed -- as they inevitably will. - Mark [1] https://github.com/williamh/pybugz From mohan.pakkurti at oracle.com Sun Jun 5 18:22:36 2011 From: mohan.pakkurti at oracle.com (Mohan Pakkurti) Date: Sun, 5 Jun 2011 18:22:36 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> Message-ID: <702394BE-1231-400E-BC61-73925F2BE87F@oracle.com> Mark, Thank you so much for the very detailed feedback. I have some comments and answers to your questions, inlined below. On Jun 4, 2011, at 10:31 PM, mark.reinhold at oracle.com wrote: > 2011/5/24 12:48 -0700, mohan.pakkurti at oracle.com: >> As you know from earlier discussions, we have been evaluating Bugzilla >> and JIRA for bug management for OpenJDK. >> >> I have posted the latest comparison notes here: >> >> http://cr.openjdk.java.net/~mo/openjdk/bugsystem/BugzillaJIRAComparison.pdf >> >> It would be great to hear your comments on this. > > Thanks for pulling all this information together. Here are some comments > and questions about it. > > - Implementation language -- You list Bugzilla as being at a > disadvantage here because it's written in Perl. I don't think the > implementation language is all that important. Regardless of which > system we choose I doubt we're going to customize it much, since > customization inevitably increases the cost of doing the next version > upgrade. We can't choose a system assuming that we are not going to customize it. Both systems will need customization and extension. In the case of JIRA there is a clearly defined plugin mechanism and there is an api to make extensions. Quite extensive extensions can be achieved using this. In the case of Bugzilla a lot of the customization is achieved by modification to the core product. Which system would we want to use? One where there is a clear api in Java and almost no modification to the core application, or one where many extensions require modifications to the core product and it is written in Perl. I am confident that there will be more relevant extensions and boundary systems developed by OpenJDK developers with a Java API, than in Perl. > - Required environment -- Why is an Apache+CGI/mod_perl environment > worse than standalone, or WAR/EAR? (Bugzilla runs just fine, by the > way, under other web servers such as lighttpd.) > > - Database -- Why is it a major concern that Bugzilla doesn't support > the Oracle database? If MySQL is good enough for bugs.mozilla.org > then it's almost certainly good enough for us. The bug system and other systems we are going to put in place for OpenJDK will be managed by a group that has a lot of experience in managing highly available application servers and Oracle databases. It is cost beneficial for the us to get hosting, management and 24x7 support if we chose a platform that is supported by this group. So, it is not exactly a disadvantage on its own, but in the deployment and support scenario that we would use, JIRA fits in better. > - Web-service API -- A critical sub-question here is whether the API > exposes all of the data and every action that's available through the > browser interface. It must be possible, in principle, to do two > things: (1) Extract all of the data in order to mirror the bug > database on another system, and (2) Create an alternative client > interface that has all the functionality of the browser interface. > To what degree do Bugzilla and JIRA support these goals? In case of both systems there are well documented methods to query and extract data from the database. Both the api's provide features to develop support new clients. Take a quick look at these links to get an idea for what the api's provide. http://www.bugzilla.org/docs/tip/en/html/api/ http://docs.atlassian.com/software/jira/docs/api/latest/ > - CLI -- For Bugzilla there's PyBugz [1], an actively-maintained Python > interface to Bugzilla which includes a CLI. > > - Identity -- I don't understand why Bugzilla is listed as requiring > third-party identity plugins. Bugzilla has full support for LDAP, a > recognized industry standard. Is that not sufficient? It could be sufficient, but I was looking at a larger picture. Ability to provide single sign on to multiple systems - bug system, code review, build and test system etc. In case of Bugzilla, we can set up a hierarcy of LDAP directories to authenticate users. But if we want to integrate to other tools that we will setup in the near future (code review, build and test systems etc.) , we need a SSO solution to hook up all our systems. With JIRA there is such a SSO solution that we could use to not only authenticate users against multiple directory servers, but also set privileges based on that. We can solve quite elegantly the issue of who can do what and when, and set up views and workflows based on roles, privilege and context. > - Access permissions -- Why do we need field-level access control? > What are the use cases for that? The bug system is going to be used for OpenJDK and also for work done on JDK for Oracle JDK. The bugs in the system could have some custom data that is relevant only to Oracle and also to protect sensitive information that is not to be displayed to users who are not OpenJDK members. > - Query language, Reports, Actions, Notifications -- The color codes of > the headings at the top of these sections indicate that Bugzilla has > "minor concerns and deficiencies", but you don't say what they are. Actually the more I look at this, the more it is clearer that the JIRA query, reporting and notification system is far more sophisticated than Bugzilla's. See http://www.bugzilla.org/docs/4.0/en/html/query.html http://www.bugzilla.org/features/#reporting http://www.bugzilla.org/docs/tip/en/html/userpreferences.html compared to http://www.atlassian.com/software/jira/tour/reporting.jsp http://www.atlassian.com/software/jira/tour/reporting.jsp http://www.atlassian.com/software/jira/full-features.jsp#access-notifications I can write a separate comparison if needed, but a quick read through of the links will give you an idea. > - Preservation of bug ids -- You say that Bugzilla can retain bug ids, > and that JIRA might be able to retain bug ids ("but needs work") and > in any case will force a project prefix ("JAVA-"). > > I consider it a hard requirement that we be able to retain existing > bug ids -- not just have special fields that cross-link to them, but > actually retain them. These ids have been used in so many places for > so many years that not retaining them is going to be a significant > ease-of-use issue. > > I also think JIRA's mandatory bug-id project prefix is, well, > ridiculous. Why must we type "JAVA-" (or "JDK-", or whatever) in > front of every single bug number? What value does that add? The > prefix convention may well be useful in a large community with many > unrelated projects, but that's not what OpenJDK is. Yes, it is a very reasonable requirement to preserve the bug numbers, and that is something to take into account. But I wonder, how critical is it that bug numbers be preserved in a new system, especially if you could search by old bug numbers anyway. The bug system will be searchable by all fields. It should not matter what the primary key of the bug is, as long as searching for a bug number in the system brings up the bug info. Users could search for a bug number, and it won't matter whether it has an old number or a new number. One value I could see for the prefix is to have prefix for different workflows, JDK-bugs, CCC-issues, EFP-requirements etc. And also being open to the future possibility that other JDK associated projects and components might use the same infrastructure that we are setting up for OpenJDK. > - Workflows -- Why is supporting multiple workflows a hard requirement? > What are the use cases? Are there ways to support those use cases by > means other than separate workflows? Wait a minute :) you were actually the first person to bring this requirement to me. This requirement falls in the category of process tools for change planning (CCC), feature planing, integrating code review and bug workflows etc. I think the ability to support these multiple workflows that support our development cycles in one tool, greatly enhances productivity by making available a lot of relevant processes and information in one place. > - Integration -- I don't understand why Bugzilla is listed as being at > such a disadvantage here. Can you please elaborate? I meant, to bring up the benefits of good integration between say the bug system, a code review system, continuous build and test system and even some process and planning tools. We have plenty of tools and systems today and one of the frequent deficiency is that the systems don't co-operate. Working in our development cycle will definitely be more enjoyable if we connected these tools well, they do after all help us to participate in the same development cycle. If we give value to the benefits that integration bring, (i do), then JIRA provides the tight integration to some other good tools. If we wanted to choose a bunch of other tools that are not already integrated, then we will pay the price for integration and the integration itself is not our core business. > Overall, I have to agree with previous comments to the effect that this > analysis seems, so far, to be somewhat biased in favor of JIRA. I look > forward to seeing answers to the questions I've raised above so that we > can make as objective a decision as possible. > > For the record, I'm not a huge fan of either of these systems. In the > end I think the most critical requirements are an underlying data model > that meets our needs together with a complete and open web API so that > alternative clients and boundary systems can be constructed -- as they > inevitably will. I talked to people in many roles and collected requirements and evaluated Bugzilla and JIRA against those requirements. There are other requirements and constraints that appear to account for thecost of ownership of a bug system both for now and the future. One of the reasons for looking for new systems for OpenJDK is to increase our efficiency. Choosing systems based on technologies we understand and can control and having thousands of engineers that are experts is in line with that. From the comparison based on our requirements one system comes out ahead, and that is JIRA. Hope these comments and answers give some context and reasoning behind the comparison. Mohan > - Mark > > > [1] https://github.com/williamh/pybugz From mohan.pakkurti at oracle.com Sun Jun 5 18:25:53 2011 From: mohan.pakkurti at oracle.com (Mohan Pakkurti) Date: Sun, 5 Jun 2011 18:25:53 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> Message-ID: Mark, Thank you so much for the very detailed feedback. I have some comments and answers to your questions, inlined below. On Jun 4, 2011, at 10:31 PM, mark.reinhold at oracle.com wrote: > 2011/5/24 12:48 -0700, mohan.pakkurti at oracle.com: >> As you know from earlier discussions, we have been evaluating Bugzilla >> and JIRA for bug management for OpenJDK. >> >> I have posted the latest comparison notes here: >> >> http://cr.openjdk.java.net/~mo/openjdk/bugsystem/BugzillaJIRAComparison.pdf >> >> It would be great to hear your comments on this. > > Thanks for pulling all this information together. Here are some comments > and questions about it. > > - Implementation language -- You list Bugzilla as being at a > disadvantage here because it's written in Perl. I don't think the > implementation language is all that important. Regardless of which > system we choose I doubt we're going to customize it much, since > customization inevitably increases the cost of doing the next version > upgrade. We can't choose a system assuming that we are not going to customize it. Both systems will need customization and extension. In the case of JIRA there is a clearly defined plugin mechanism and there is an api to make extensions. Quite extensive extensions can be achieved using this. In the case of Bugzilla a lot of the customization is achieved by modification to the core product. Which system would we want to use? One where there is a clear api in Java and almost no modification to the core application, or one where many extensions require modifications to the core product and it is written in Perl. I am confident that there will be more relevant extensions and boundary systems developed by OpenJDK developers with a Java API, than in Perl. > - Required environment -- Why is an Apache+CGI/mod_perl environment > worse than standalone, or WAR/EAR? (Bugzilla runs just fine, by the > way, under other web servers such as lighttpd.) > > - Database -- Why is it a major concern that Bugzilla doesn't support > the Oracle database? If MySQL is good enough for bugs.mozilla.org > then it's almost certainly good enough for us. The bug system and other systems we are going to put in place for OpenJDK will be managed by a group that has a lot of experience in managing highly available application servers and Oracle databases. It is cost beneficial for the us to get hosting, management and 24x7 support if we chose a platform that is supported by this group. So, it is not exactly a disadvantage on its own, but in the deployment and support scenario that we would use, JIRA fits in better. > - Web-service API -- A critical sub-question here is whether the API > exposes all of the data and every action that's available through the > browser interface. It must be possible, in principle, to do two > things: (1) Extract all of the data in order to mirror the bug > database on another system, and (2) Create an alternative client > interface that has all the functionality of the browser interface. > To what degree do Bugzilla and JIRA support these goals? In case of both systems there are well documented methods to query and extract data from the database. Both the api's provide features to develop support new clients. Take a quick look at these links to get an idea for what the api's provide. http://www.bugzilla.org/docs/tip/en/html/api/ http://docs.atlassian.com/software/jira/docs/api/latest/ > - CLI -- For Bugzilla there's PyBugz [1], an actively-maintained Python > interface to Bugzilla which includes a CLI. > > - Identity -- I don't understand why Bugzilla is listed as requiring > third-party identity plugins. Bugzilla has full support for LDAP, a > recognized industry standard. Is that not sufficient? It could be sufficient, but I was looking at a larger picture. Ability to provide single sign on to multiple systems - bug system, code review, build and test system etc. In case of Bugzilla, we can set up a hierarcy of LDAP directories to authenticate users. But if we want to integrate to other tools that we will setup in the near future (code review, build and test systems etc.) , we need a SSO solution to hook up all our systems. With JIRA there is such a SSO solution that we could use to not only authenticate users against multiple directory servers, but also set privileges based on that. We can solve quite elegantly the issue of who can do what and when, and set up views and workflows based on roles, privilege and context. > - Access permissions -- Why do we need field-level access control? > What are the use cases for that? The bug system is going to be used for OpenJDK and also for work done on JDK for Oracle JDK. The bugs in the system could have some custom data that is relevant only to Oracle and also to protect sensitive information that is not to be displayed to users who are not OpenJDK members. > - Query language, Reports, Actions, Notifications -- The color codes of > the headings at the top of these sections indicate that Bugzilla has > "minor concerns and deficiencies", but you don't say what they are. Actually the more I look at this, the more it is clearer that the JIRA query, reporting and notification system is far more sophisticated than Bugzilla's. See http://www.bugzilla.org/docs/4.0/en/html/query.html http://www.bugzilla.org/features/#reporting http://www.bugzilla.org/docs/tip/en/html/userpreferences.html compared to http://www.atlassian.com/software/jira/tour/reporting.jsp http://www.atlassian.com/software/jira/tour/reporting.jsp http://www.atlassian.com/software/jira/full-features.jsp#access-notifications I can write a separate comparison if needed, but a quick read through of the links will give you an idea. > - Preservation of bug ids -- You say that Bugzilla can retain bug ids, > and that JIRA might be able to retain bug ids ("but needs work") and > in any case will force a project prefix ("JAVA-"). > > I consider it a hard requirement that we be able to retain existing > bug ids -- not just have special fields that cross-link to them, but > actually retain them. These ids have been used in so many places for > so many years that not retaining them is going to be a significant > ease-of-use issue. > > I also think JIRA's mandatory bug-id project prefix is, well, > ridiculous. Why must we type "JAVA-" (or "JDK-", or whatever) in > front of every single bug number? What value does that add? The > prefix convention may well be useful in a large community with many > unrelated projects, but that's not what OpenJDK is. Yes, it is a very reasonable requirement to preserve the bug numbers, and that is something to take into account. But I wonder, how critical is it that bug numbers be preserved in a new system, especially if you could search by old bug numbers anyway. The bug system will be searchable by all fields. It should not matter what the primary key of the bug is, as long as searching for a bug number in the system brings up the bug info. Users could search for a bug number, and it won't matter whether it has an old number or a new number. One value I could see for the prefix is to have prefix for different workflows, JDK-bugs, CCC-issues, EFP-requirements etc. And also being open to the future possibility that other JDK associated projects and components might use the same infrastructure that we are setting up for OpenJDK. > - Workflows -- Why is supporting multiple workflows a hard requirement? > What are the use cases? Are there ways to support those use cases by > means other than separate workflows? Wait a minute :) you were actually the first person to bring this requirement to me. This requirement falls in the category of process tools for change planning (CCC), feature planing, integrating code review and bug workflows etc. I think the ability to support these multiple workflows that support our development cycles in one tool, greatly enhances productivity by making available a lot of relevant processes and information in one place. > - Integration -- I don't understand why Bugzilla is listed as being at > such a disadvantage here. Can you please elaborate? I meant, to bring up the benefits of good integration between say the bug system, a code review system, continuous build and test system and even some process and planning tools. We have plenty of tools and systems today and one of the frequent deficiency is that the systems don't co-operate. Working in our development cycle will definitely be more enjoyable if we connected these tools well, they do after all help us to participate in the same development cycle. If we give value to the benefits that integration bring, (i do), then JIRA provides the tight integration to some other good tools. If we wanted to choose a bunch of other tools that are not already integrated, then we will pay the price for integration and the integration itself is not our core business. > Overall, I have to agree with previous comments to the effect that this > analysis seems, so far, to be somewhat biased in favor of JIRA. I look > forward to seeing answers to the questions I've raised above so that we > can make as objective a decision as possible. > > For the record, I'm not a huge fan of either of these systems. In the > end I think the most critical requirements are an underlying data model > that meets our needs together with a complete and open web API so that > alternative clients and boundary systems can be constructed -- as they > inevitably will. I talked to people in many roles and collected requirements and evaluated Bugzilla and JIRA against those requirements. There are other requirements and constraints that appear to account for thecost of ownership of a bug system both for now and the future. One of the reasons for looking for new systems for OpenJDK is to increase our efficiency. Choosing systems based on technologies we understand and can control and having thousands of engineers that are experts is in line with that. From the comparison based on our requirements one system comes out ahead, and that is JIRA. Hope these comments and answers give some context and reasoning behind the comparison. Mohan > - Mark > > > [1] https://github.com/williamh/pybugz From roger.calnan at oracle.com Sun Jun 5 20:55:47 2011 From: roger.calnan at oracle.com (Roger Calnan) Date: Sun, 5 Jun 2011 20:55:47 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> Message-ID: <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> > I am confident that there will be more relevant extensions and boundary > systems developed by OpenJDK developers with a Java API, than in Perl. I suspect that the language won't impact the relevance of the extensions but for us we are far more likely to find expertise in Java vs. Perl for the set of people who will have an interest in deploying/maintaing and extending the system. > The bug system and other systems we are going to put in place for > OpenJDK will be managed by a group that has a lot of experience in > managing highly available application servers and Oracle databases. > It is cost beneficial for the us to get hosting, management and 24x7 > support if we chose a platform that is supported by this group. I'd agree with Mark that MySQL would be fine for our needs, but as with the first item when we work with the internal hosting groups there will be far more experience/expertise with the Oracle database. With this and the Perl/Java question my position is that the choice of the bug DB isn't going to make us succeed or fail, both can do the job. However we want the lowest "cost" solution as we end up putting lots of effort into the bug system it will distract us from JDK 8/9 etc. which is where we will really succeed or fail. >> - Access permissions -- Why do we need field-level access control? >> What are the use cases for that? > > The bug system is going to be used for OpenJDK and also for work done > on JDK for Oracle JDK. The bugs in the system could have some custom data > that is relevant only to Oracle and also to protect sensitive information that is > not to be displayed to users who are not OpenJDK members. Today we can likely deploy a solution without field level security, however I think that there will be information (such as security descriptions etc.) that we will want to share with the OpenJDK partners who are producing a JRE for their platform where we will want to be able to share information that won't go to the general OpenJDK developer population. The more we can have this information in the bug system vs. email the better. >> - Preservation of bug ids -- You say that Bugzilla can retain bug ids, >> and that JIRA might be able to retain bug ids ("but needs work") and >> in any case will force a project prefix ("JAVA-"). >> >> I consider it a hard requirement that we be able to retain existing >> bug ids -- not just have special fields that cross-link to them, but >> actually retain them. These ids have been used in so many places for >> so many years that not retaining them is going to be a significant >> ease-of-use issue. >> >> I also think JIRA's mandatory bug-id project prefix is, well, >> ridiculous. Why must we type "JAVA-" (or "JDK-", or whatever) in >> front of every single bug number? What value does that add? The >> prefix convention may well be useful in a large community with many >> unrelated projects, but that's not what OpenJDK is. > > Yes, it is a very reasonable requirement to preserve the bug numbers, and > that is something to take into account. But I wonder, how critical is it that > bug numbers be preserved in a new system, especially if you could search > by old bug numbers anyway. mandating a prefix is ugly, I can see why it seemed like a good idea but it not being optional is a pain. From initial conversations with JIRA experts it looks like we could have jdk-4040458 etc. (ie. preserve the existing numbering) and start all new bugs above jdk-8000000 but as much as possible I'd say we hide/auto-populate the prefix. > One value I could see for the prefix is to have prefix for different workflows, > JDK-bugs, CCC-issues, EFP-requirements etc. And also being open to the future > possibility that other JDK associated projects and components might use the > same infrastructure that we are setting up for OpenJDK. for CCC (this is the tool that we have used to track compatibility issues) the requests have a 1:1 mapping with bugs and so we would want that the CCC request for a bug 4040458 would have an equivalent ccc-4040458, but no doubt that would cause JIRA some problems as we would be allocating the IDs in a non-linear fashion. EFP- (Engineering Feature Proposal, a response to a requirement) makes sense as a feature could result in a number of bugs and RFEs. >> Overall, I have to agree with previous comments to the effect that this >> analysis seems, so far, to be somewhat biased in favor of JIRA. I look >> forward to seeing answers to the questions I've raised above so that we >> can make as objective a decision as possible. I don't see that this analysis is far off from the initial one we published. Mohan's group have put in a lot more effort into the actual implementation and I think that is what is swaying us to an answer more than biasing the results. >> For the record, I'm not a huge fan of either of these systems. In the >> end I think the most critical requirements are an underlying data model >> that meets our needs together with a complete and open web API so that >> alternative clients and boundary systems can be constructed -- as they >> inevitably will. agreed and JIRA/Bugzilla both allow that. However if we have more than a few engineers spending time on developing such systems we are wasting our time as the end of the day we should be putting our efforts into improving Java vs. the bug system each of which have lots of people who find developing bug systems interesting helping to improve them. We don't, we want a tool that just works. > One of the reasons for looking for new systems for OpenJDK is to increase > our efficiency. this is key. > Choosing systems based on technologies we understand and > can control and having thousands of engineers that are experts is in line with that. again hopefully the bug system won't be our focus once we get going, however these points are valid for the group that will be implementing and maintaining the system moving forward. > From the comparison based on our requirements one system comes out ahead, and that is JIRA. let's move this effort into the decision phase as this clearly we won't make a choice that pleases everyone, but we need a decision and move on. We can't duck (avoid) a decision as we can with the netbeans vs. eclipse vs. emacs question, luckily.... Roger From kelly.ohair at oracle.com Mon Jun 6 11:13:06 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 6 Jun 2011 11:13:06 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> Message-ID: <4D857CE7-E2D8-4405-98DE-DFB2B9A95B48@oracle.com> On Jun 5, 2011, at 8:55 PM, Roger Calnan wrote: >> >> From the comparison based on our requirements one system comes out ahead, and that is JIRA. > let's move this effort into the decision phase as this clearly we won't > make a choice that pleases everyone, but we need a decision and move on. I agree. --- Regardless of any perceptions that this analysis might have been biased, I don't see it that way. I have not been directly involved in this analysis, except as a deeply interested bystander. In any evaluation like this, given the list of requirements, sometimes one choice starts standing out well above the other, and the resulting report may appear to be biased when it is actually reflecting the obvious choice that stood out during the analysis. I'm not a huge fan of any bug tracking system, and with any new one I am given to use, I will grumble and complain like everyone else, initially, then learn to live with it, or fix it. Let's get it in place and move on. It's like the kids in the car that keep asking "Are we there yet?". I'd like to say "Yes! Now will you shut up!" Nicely. ;^) -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20110606/92da89d0/attachment.html From joe.darcy at oracle.com Tue Jun 7 17:50:41 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jun 2011 17:50:41 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> Message-ID: <4DEEC761.2010603@oracle.com> Roger Calnan wrote: [snip] >> One value I could see for the prefix is to have prefix for different workflows, >> JDK-bugs, CCC-issues, EFP-requirements etc. And also being open to the future >> possibility that other JDK associated projects and components might use the >> same infrastructure that we are setting up for OpenJDK. >> > for CCC (this is the tool that we have used to track compatibility issues) > the requests have a 1:1 mapping with bugs and so we would want that the > CCC request for a bug 4040458 would have an equivalent ccc-4040458, but > no doubt that would cause JIRA some problems as we would be allocating > the IDs in a non-linear fashion. EFP- (Engineering Feature Proposal, a > response to a requirement) makes sense as a feature could result in a > number of bugs and RFEs. > As current ccc chairman, I would much prefer the ccc process of reviewing the compatibility impact and overall design of a JDK interface change [1] to be directly integrated into and supported by the new bug system rather than being a stand-alone system. I have not looked into the separate workflow capabilities of either system, but I had envisioned such a workflow as being managed on adjunct data kept as part of the same bug and not requiring a separate bug per se. -Joe [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#kinds_of_interfaces From anthony.petrov at oracle.com Wed Jun 8 01:20:40 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Jun 2011 12:20:40 +0400 Subject: Update on bug system for OpenJDK In-Reply-To: <4DEEC761.2010603@oracle.com> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> <4DEEC761.2010603@oracle.com> Message-ID: <4DEF30D8.5060402@oracle.com> On 6/8/2011 4:50 AM, Joe Darcy wrote: > As current ccc chairman, I would much prefer the ccc process of > reviewing the compatibility impact and overall design of a JDK interface > change [1] to be directly integrated into and supported by the new bug > system rather than being a stand-alone system. > > I have not looked into the separate workflow capabilities of either > system, but I had envisioned such a workflow as being managed on adjunct > data kept as part of the same bug and not requiring a separate bug per se. +1! That would be much more convenient for engineers as well. -- best regards, Anthony > [1] > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#kinds_of_interfaces From spoole at linux.vnet.ibm.com Wed Jun 8 08:28:53 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 08 Jun 2011 16:28:53 +0100 Subject: Update on code review system for OpenJDK In-Reply-To: References: <2350A47F-43E5-4950-85D5-514EAC300736@oracle.com> <4DDFCEFE.9090201@gmx.de> Message-ID: <4DEF9535.8060008@linux.vnet.ibm.com> On 28/05/11 16:08, Martijn Verburg wrote: > Hi all, > > I've used Crucible a couple of times and quite like it. It gives you > the ability to comment on a particular line/section of code or just > make an overall comment. Being able to classify the comment as a > Defect, license missing etc is also very helpful. > > I will say that it's UI and therefore workflow can be a little > overwhelming. I think somebody would have to put together a "How To" > guide or the Crucible admins might be able to simplify things down > somewhat. > > If JIRA is chosen as the issue tracker, then Crucible is a nice > tie-in. I found being able to jump from the JIRA issue to the code > review and back again was really useful, especially if I was not > intimately familiar with the code. I agree that if Jira is choosen then taking Crucible becomes even more attractive. I've not used Crucible so I will go take it for a spin. Let you know what I think. > Cheers, > Martijn > > On 27 May 2011 17:19, Ulf Zibis wrote: >> Additional Points: >> - Usability on Windows >> The current webrev script is practically unusable on Windows. 1., making it >> to run via Cygwin is not quite easy, 2. needs incredible performance and 3. >> it crashes by stack overflow, if more than ~8 files are involved. >> >> - Performance for creating a WebRev >> The current webrev script needs much performance. >> >> -Ulf >> >> >> Am 27.05.2011 17:29, schrieb Mohan Pakkurti: >>> Hi all, >>> >>> In april I posted a request for use cases and features for a code review >>> system for OpenJDK. >>> >>> I have aggregated the many enthusiastic replies received in response, and >>> did a comparison of Review Board and Crucible. >>> >>> Here are some preliminary findings from the comparison: >>> >>> >>> http://cr.openjdk.java.net/~mo/openjdk/codereview/ReviewboardCrucibleComparison.pdf >>> >>> Let me know if there are any more requirements you want to add to this >>> list. If you have experience using these systems, please do share your >>> impressions about these tools. >>> >>> Thanks >>> >>> Mohan >>> >>> From spoole at linux.vnet.ibm.com Wed Jun 8 08:40:44 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 08 Jun 2011 16:40:44 +0100 Subject: Update on bug system for OpenJDK In-Reply-To: <4D857CE7-E2D8-4405-98DE-DFB2B9A95B48@oracle.com> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> <4D857CE7-E2D8-4405-98DE-DFB2B9A95B48@oracle.com> Message-ID: <4DEF97FC.8000805@linux.vnet.ibm.com> On 06/06/11 19:13, Kelly O'Hair wrote: > > On Jun 5, 2011, at 8:55 PM, Roger Calnan wrote: > >>> >>> From the comparison based on our requirements one system comes out >>> ahead, and that is JIRA. >> let's move this effort into the decision phase as this clearly we won't >> make a choice that pleases everyone, but we need a decision and move on. > > I agree. > > --- > > Regardless of any perceptions that this analysis might have > been biased, I don't see it that way. > I have not been directly involved in this analysis, except as a deeply > interested bystander. > In any evaluation like this, given the list of requirements, sometimes > one choice starts standing out > well above the other, and the resulting report may appear to be biased > when it is actually reflecting the > obvious choice that stood out during the analysis. > > I'm not a huge fan of any bug tracking system, and with any new one I > am given to use, I will grumble and > complain like everyone else, initially, then learn to live with it, or > fix it. Let's get it in place and move on. yep - my sentiments too. We need to move towards a public proof-of-concept now so we can see how it could work before committing to a final configuration. > > It's like the kids in the car that keep asking "Are we there yet?". > I'd like to say "Yes! Now will you shut up!" Nicely. ;^) > > -kto > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20110608/1140d1d8/attachment.html From kelly.ohair at oracle.com Wed Jun 8 08:48:40 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 8 Jun 2011 08:48:40 -0700 Subject: Update on bug system for OpenJDK In-Reply-To: <4DEF30D8.5060402@oracle.com> References: <20110605053120.4CA4B1A81@eggemoggin.niobe.net> <4872A8C9-D7B3-431B-81EA-6C4C1CBACDA4@oracle.com> <4DEEC761.2010603@oracle.com> <4DEF30D8.5060402@oracle.com> Message-ID: On Jun 8, 2011, at 1:20 AM, Anthony Petrov wrote: > On 6/8/2011 4:50 AM, Joe Darcy wrote: >> As current ccc chairman, I would much prefer the ccc process of reviewing the compatibility impact and overall design of a JDK interface change [1] to be directly integrated into and supported by the new bug system rather than being a stand-alone system. >> I have not looked into the separate workflow capabilities of either system, but I had envisioned such a workflow as being managed on adjunct data kept as part of the same bug and not requiring a separate bug per se. > > +1! > > That would be much more convenient for engineers as well. +1 from me too. Good idea. -kto > > -- > best regards, > Anthony > >> [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#kinds_of_interfaces From spoole at linux.vnet.ibm.com Tue Jun 14 04:36:08 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 14 Jun 2011 12:36:08 +0100 Subject: Update on code review system for OpenJDK In-Reply-To: <4DEF9535.8060008@linux.vnet.ibm.com> References: <2350A47F-43E5-4950-85D5-514EAC300736@oracle.com> <4DDFCEFE.9090201@gmx.de> <4DEF9535.8060008@linux.vnet.ibm.com> Message-ID: <4DF747A8.4070806@linux.vnet.ibm.com> On 08/06/11 16:28, Steve Poole wrote: > I agree that if Jira is choosen then taking Crucible becomes even > more attractive. > I've not used Crucible so I will go take it for a spin. Let you know > what I think. I did watch the video (http://www.atlassian.com/software/crucible/videos/crucible-overview.jsp) and the tool looks cool. I played with the sandbox version online a bit and it seems fine - no immediate horrors. Coupled with Jira and fisheye I'd say that it really would be worth setting up a prototype environment and experimenting. There is a lot of good stuff here and the best way to evaluate it is via some hands-on activities.