From mark at klomp.org Mon Oct 1 00:58:57 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 01 Oct 2007 09:58:57 +0200 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> Message-ID: <1191225537.3842.15.camel@dijkstra.wildebeest.org> Hi, On Fri, 2007-09-28 at 10:57 -0700, iris.clark at sun.com wrote: > I'd like to propose creation of the OpenJDK Conformance Group. The > intent of this group is to discuss conformance testing and > compatibility issues. Topics for discussion include: > > - Defining conformance testing > - Understanding the importance of compatibility between releases > - Distinguishing between conformance and product tests This sound great. One idea for this is inviting Stuart Ballard (CCed). His japitools http://www.kaffe.org/~stuart/japi/ have been a great part of the communities conformance and compatibility drive. Does it have to be a separate group? Couldn't this be part of the quality group? They already have a (pretty quiet) mailinglist and infrastructure on the website. It seems conformance is just one bit of the quality process overall. > - Acquiring the JCK for an OpenJDK project > - Configuring and running the JCK > - Contributing new JCK tests > > This group will have two mailing lists. The first is open to everyone > and will contain discussions around compatibility, conformance > testing, and general JCK installation and usability. The second > mailing list is open only to group members who have signed the OpenJDK > Community TCK Licensee Agreement. Discussions on this list will focus > on understanding the behavior and validity of specific tests and other > confidential materials. I do have my doubts about this second part though. Is it really in the interest of the openjdk project to have secret lists where proprietary software is discussed without the rest of the community being able to see, share and help out? The thing I like about OpenJDK is that it is a free software community, where all software and ideas are shared in the open. There are still of course the binary blobs and the jtreg suite, but my understanding is that those will be liberated over time (as icedtea and mauve have shown can already be done). Is the idea that over time the JCK will also become a proper part of OpenJDK under a free license? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/discuss/attachments/20071001/d1e5afec/attachment.bin From gnu_andrew at member.fsf.org Mon Oct 1 04:41:26 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 1 Oct 2007 12:41:26 +0100 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <1191225537.3842.15.camel@dijkstra.wildebeest.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> Message-ID: <200710011241.27161.gnu_andrew@member.fsf.org> On Monday 01 October 2007 08:58:57 Mark Wielaard wrote: > Hi, > > On Fri, 2007-09-28 at 10:57 -0700, iris.clark at sun.com wrote: > > I'd like to propose creation of the OpenJDK Conformance Group. The > > intent of this group is to discuss conformance testing and > > compatibility issues. Topics for discussion include: > > > > - Defining conformance testing > > - Understanding the importance of compatibility between releases > > - Distinguishing between conformance and product tests > > This sound great. One idea for this is inviting Stuart Ballard (CCed). > His japitools http://www.kaffe.org/~stuart/japi/ have been a great part > of the communities conformance and compatibility drive. > Seconded; Stuart's tools have been invaluable during the development of GNU Classpath and are equally applicable as general tools for ensuring binary API compatabillity between releases. > Does it have to be a separate group? Couldn't this be part of the > quality group? They already have a (pretty quiet) mailinglist and > infrastructure on the website. It seems conformance is just one bit of > the quality process overall. > I agree, there are already an overly burdernsome number of mailing lists and groups and conformance would intrinsicly seem to be part of a drive for quality. The quality page already has plenty of nice metrics: http://openjdk.java.net/groups/quality/ It would seem an appropriate place for further conformance-related ones. > > - Acquiring the JCK for an OpenJDK project > > - Configuring and running the JCK > > - Contributing new JCK tests > > > > This group will have two mailing lists. The first is open to everyone > > and will contain discussions around compatibility, conformance > > testing, and general JCK installation and usability. The second > > mailing list is open only to group members who have signed the OpenJDK > > Community TCK Licensee Agreement. Discussions on this list will focus > > on understanding the behavior and validity of specific tests and other > > confidential materials. > > I do have my doubts about this second part though. Is it really in the > interest of the openjdk project to have secret lists where proprietary > software is discussed without the rest of the community being able to > see, share and help out? The thing I like about OpenJDK is that it is a > free software community, where all software and ideas are shared in the > open. There are still of course the binary blobs and the jtreg suite, > but my understanding is that those will be liberated over time (as > icedtea and mauve have shown can already be done). Is the idea that over > time the JCK will also become a proper part of OpenJDK under a free > license? > This is indicative of what my feelings about the OpenJDK project have been so far unfortunately. I'd like, as would many GNU Classpath members, to see it blossom with a rich interacting community but this won't happen while large parts of the process remain behind closed doors. I can understand if there needs to be some private discussion between licensees but the development of the test suite should be done in public, by the community, with the long term goal of an open test suite under a Free software license. To my mind, the whole certification process should be just one element of the test suite, not its primary motivation. We've developed Mauve because the JDK test suite was inaccessible in the past, and I hope this is not the way things are going to continue. It would be nice to instead merge these efforts and work together to create the best possible test suite. > Cheers, > > Mark Cheers, -- Andrew :) From David.Herron at Sun.COM Mon Oct 1 07:27:10 2007 From: David.Herron at Sun.COM (David Herron) Date: Mon, 01 Oct 2007 07:27:10 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <200710011241.27161.gnu_andrew@member.fsf.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> Message-ID: <470103BE.8050806@sun.com> Andrew John Hughes wrote: > On Monday 01 October 2007 08:58:57 Mark Wielaard wrote: > >> Hi, >> >> On Fri, 2007-09-28 at 10:57 -0700, iris.clark at sun.com wrote: >> >>> I'd like to propose creation of the OpenJDK Conformance Group. The >>> intent of this group is to discuss conformance testing and >>> compatibility issues. Topics for discussion include: >>> >>> - Defining conformance testing >>> - Understanding the importance of compatibility between releases >>> - Distinguishing between conformance and product tests >>> >> This sound great. One idea for this is inviting Stuart Ballard (CCed). >> His japitools http://www.kaffe.org/~stuart/japi/ have been a great part >> of the communities conformance and compatibility drive. >> >> > > Seconded; Stuart's tools have been invaluable during the development of GNU > Classpath and are equally applicable as general tools for ensuring binary API > compatabillity between releases. > We use some similar tools in-house. >> Does it have to be a separate group? Couldn't this be part of the >> quality group? They already have a (pretty quiet) mailinglist and >> infrastructure on the website. It seems conformance is just one bit of >> the quality process overall. >> >> > > I agree, there are already an overly burdernsome number of mailing lists and > groups and conformance would intrinsicly seem to be part of a drive for > quality. > > The quality page already has plenty of nice metrics: > > http://openjdk.java.net/groups/quality/ > > It would seem an appropriate place for further conformance-related ones. > Thank you for the kind words about the Quality group pages. Originally the Conformance and Quality were going to be together in the same group. Shortly before the launch at Java ONE we decided they were better kept apart. It seems that while both teams spend a lot of time writing tests, the purpose and focus is different. Conformance to the spec is a different question than is the platform good quality. I agree that "does it conform to the spec" is clearly part of whether the thing has high quality. At the same time there are many other measures of quality. And the intentional focus is different. Conformance may seem as you say just a small part of the overall quality process. Both teams have a significant number of engineers, which I think is indicative of the significance of Conformance to validating the platform. I don't know the numbers but the SQE and JCK teams are closer to equal size than you might expect. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071001/32ebdc50/attachment.html From Xiomara.Jayasena at Sun.COM Mon Oct 1 11:02:03 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Mon, 01 Oct 2007 11:02:03 -0700 Subject: Crypto has been added to OpenJDK In-Reply-To: <46FD5122.7030305@kaffe.org> References: <46FC2E29.9080707@sun.com> <46FC3CA3.20607@sun.com> <46FCD99F.9030802@kaffe.org> <46FD29FA.40706@sun.com> <46FD5122.7030305@kaffe.org> Message-ID: <4701361B.7060904@Sun.COM> Dalibor Topic wrote: >Brad Wetmore wrote: > > >>Dalibor Topic wrote: >> >> >>>Janet Koenig wrote: >>> >>> >>>>That's great news! I know this has been a big challenge so thanks for >>>>continuing to drive this and making it happen! >>>>Regards, >>>>Janet >>>> >>>> >>>Thanks from over here, too. >>> >>> >>You're welcome. It was a...challenge, as Janet said. :) >> >> > >I bet. Thank you very much for pushing through. > > > >>>No blog on planetjdk.org on it yet? ;) >>> >>> >>I've yet to create a blog. It's been on my to-do list for far too long. >> I would probably end up blogging about my outside pursuits, which might >>be boring unless you like marching bands, travel, or pyrotechnics (not >>the internal politics kind, but the ones in the sky). ;) >> >> > >>From our experience on planet.classpath.org, the 'other' side of the >people one's working together in a free software project is pretty >important in creating the sort of social glue that binds communities, in >particular in virtual ones. ;) > > > >>I should really create one, I've got a couple topics that you might be >>interested in from the internal perspective. I'm one of several >>gatekeepers, so I started writing a couple ideas down about how our >>internal "gatekeeper" process works, and the overall process of getting >>fixes into OpenJDK while making sure the quality stays up. The quality >>*HAS* to stay up, as people will be betting their businesses (or have >>already) on the code all of us will be developing. Coding in this >>project is an awesome responsibility, and one that is sometime lost by >>people who just want to "play with something." >> >> > >Great, I think it would be fascinating to hear more about the processes >you have in place internally, and how you see them evolve/adapt for >OpenJDK. > >For those of us outside Sun, the more transparent the 'black process >boxes' are, the better we can understand what's going on, and where to >assist to get things moving in the right direction, if possible/desirable. > > > >>Anyway, this quality perspective is "common knowledge" to us >>gatekeepers, so it might be worth sharing details about what really goes >>on in the trenches. It is probably a good topic for a blog rather than >>this email, so maybe I'll get off my duff and do it soon. >> >> > >Yes, please. ;) > > > >>Oh, and how the coming switch to Mercurial will rock our internal world. >> So many build/test scripts to update. >> >>Brad >> >>P.S. When I had gatekeeper duty years ago, if someone "broke the >>build," I would hang a hangman's noose made from an power cord over >>their office doorway. You didn't want the noose, because everyone knew >>what it meant without saying anything. I haven't quite figured out how >>to do a virtual noose, so please, just don't "break the build." ;) >> >> > >Speaking of that ... what sort of an automated build system do you use, >and do you plan to make the build status for the different >configurations available, a la mozilla's tinderbox [1]? > > There is automated nigtly builds for the product build. At some point when we do build the openjdk on a nightly basis, we will look into making the build status available. -Xiomara >cheers, >dalibor topic > >[1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071001/008fdc30/attachment.html From mark at klomp.org Mon Oct 1 12:16:15 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 01 Oct 2007 21:16:15 +0200 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <470103BE.8050806@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> <470103BE.8050806@sun.com> Message-ID: <1191266175.3842.72.camel@dijkstra.wildebeest.org> Hi David, On Mon, 2007-10-01 at 07:27 -0700, David Herron wrote: > Andrew John Hughes wrote: > > On Monday 01 October 2007 08:58:57 Mark Wielaard wrote: > > > > > This sound great. One idea for this is inviting Stuart Ballard (CCed). > > > His japitools http://www.kaffe.org/~stuart/japi/ have been a great part > > > of the communities conformance and compatibility drive. > > > > Seconded; Stuart's tools have been invaluable during the development of GNU > > Classpath and are equally applicable as general tools for ensuring binary API > > compatabillity between releases. > > > > We use some similar tools in-house. So, how do they compare to japi-tools? How are they used? Are the results of running the tools and the source available to the public? And are they intended to become free software as part of openjdk? > > The quality page already has plenty of nice metrics: > > > > http://openjdk.java.net/groups/quality/ > > > > It would seem an appropriate place for further conformance-related ones. > > > > Thank you for the kind words about the Quality group pages. It is deserved. If only you promoted it more and talked about it more. It really is worth it. Maybe you could post something whenever one of the metrics pages shows something interesting or surprising. > Both teams have a significant number of engineers, which I think is > indicative of the significance of Conformance to validating the > platform. I don't know the numbers but the SQE and JCK teams are > closer to equal size than you might expect. But will those engineers actually participate in openjdk? The reason we probably don't expect anything is that to be honest you guys and girls are awfully quiet! The last posting on the quality-discuss [*] was 3 months ago... So the question really is whether or not for an email once every couple of months we need a whole new group, project and separate mailinglists and webpages? It is really hard to keep track of openjdk already with all those separate, sparse groups for someone not on the inside of Sun. Cheers, Mark [*] Bug report! http://openjdk.java.net/groups/quality/ mentions a list called quality-dev which doesn't seem to exist, or is this where all the discussion really goes to? From robilad at kaffe.org Mon Oct 1 14:57:45 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Mon, 01 Oct 2007 23:57:45 +0200 Subject: Crypto has been added to OpenJDK In-Reply-To: <46FDD0B1.9010502@sun.com> References: <46FC2E29.9080707@sun.com> <46FC3CA3.20607@sun.com> <46FCD99F.9030802@kaffe.org> <46FD29FA.40706@sun.com> <46FD5122.7030305@kaffe.org> <46FDB9B7.3040605@sun.com> <46FDD0B1.9010502@sun.com> Message-ID: <47016D59.2080906@kaffe.org> David Herron wrote: > Some of us have looked into using hudson .. but nothing is firmly > settled on what to do with it, whether to host it externally, etc. So > far it looks like Hudson is really nifty. Yes. I had an instance for bootstrapping kaffe builds up and running locally in no time. It's very easy to use, and looks nice on screenshots, too. ;) cheers, dalibor topic From mr at sun.com Mon Oct 1 17:59:45 2007 From: mr at sun.com (Mark Reinhold) Date: Mon, 01 Oct 2007 17:59:45 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: mark@klomp.org; Mon, 01 Oct 2007 09:58:57 +0200; <1191225537.3842.15.camel@dijkstra.wildebeest.org> Message-ID: <20071002005945.90D8661E8@eggemoggin.niobe.net> > Date: Mon, 01 Oct 2007 09:58:57 +0200 > From: Mark Wielaard > On Fri, 2007-09-28 at 10:57 -0700, iris.clark at sun.com wrote: >> >> ... The second >> mailing list is open only to group members who have signed the OpenJDK >> Community TCK Licensee Agreement. Discussions on this list will focus >> on understanding the behavior and validity of specific tests and other >> confidential materials. > > I do have my doubts about this second part though. Is it really in the > interest of the openjdk project to have secret lists where proprietary > software is discussed without the rest of the community being able to > see, share and help out? The thing I like about OpenJDK is that it is a > free software community, where all software and ideas are shared in the > open. I agree that a proprietary TCK and a private discussion list do not align with Free Software ideals. I think that the OpenJDK TCK license is, nonetheless, such a significant improvement on the past situation that many distributors and developers will be interested in using the TCK despite its proprietary nature, and in discussing specific tests and results with other TCK licensees as well as with Sun's TCK team. The obvious place to host such discussions is on openjdk.java.net. We could host the private list elsewhere, but then it'd be harder to find and likely not archived. We could also simply drop the idea of even a private list and instead keep all discussions 1:1 between each licensee and Sun, but that would mean missing the opportunity to foster an effective sub-community of TCK licensees, and that'd be a shame. > There are still of course the binary blobs and the jtreg suite, > but my understanding is that those will be liberated over time Correct. > (as > icedtea and mauve have shown can already be done). Is the idea that over > time the JCK will also become a proper part of OpenJDK under a free > license? As a wise man once said, my crystal ball is very cloudy. - Mark From amitksaha at netbeans.org Wed Oct 3 05:33:16 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Wed, 3 Oct 2007 18:03:16 +0530 Subject: Open JDK vs Sun JDK Message-ID: <547db2260710030533t5da483b2p3583a6675631edc7@mail.gmail.com> Hello all! I am working on an article which has "Open JDK vs Sun JDK" as its theme. The agenda for the article is roughly as follows: 1. The motive behind Open JDK 2. Licensing issues related to Open JDK 3. What should people - programmers (hobbyist, professional) adopt - Open JDK or Sun JDK? Can we call one "better" than the other? Who is Open JDK mainly targeted at? 4. Future plans for Open JDK and Sun JDK. 5. Which is the future? - Open JDK or Sun JDK I am not sure if this is the proper list, in that case, please point me to the appropriate place. I shall really appreciate some insights into all or some of the topics mentioned above. Thanks, Amit -- Amit Kumar Saha *NetBeans Community Docs Coordinator* me blogs@ http://amitksaha.blogspot.com URL:http://amitsaha.in.googlepages.com From mark at klomp.org Wed Oct 3 06:10:42 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 03 Oct 2007 15:10:42 +0200 Subject: Open JDK vs Sun JDK In-Reply-To: <547db2260710030533t5da483b2p3583a6675631edc7@mail.gmail.com> References: <547db2260710030533t5da483b2p3583a6675631edc7@mail.gmail.com> Message-ID: <1191417042.3891.18.camel@dijkstra.wildebeest.org> Hi Amit, On Wed, 2007-10-03 at 18:03 +0530, Amit Kumar Saha wrote: > I am working on an article which has "Open JDK vs Sun JDK" as its > theme. Nice, let us know when and where it will be published. I think the title/theme is slightly wrong though. Try changing 'vs' to something like 'extends', see below... > The agenda for the article is roughly as follows: > > 1. The motive behind Open JDK Having fun with the community! :) There are a lot of official motives listed at: http://www.sun.com/software/opensource/java/faq.jsp > 2. Licensing issues related to Open JDK Almost everything is released under the GPL now. There are a couple of pieces that couldn't be released right now. These are being worked on by various groups to make everything available under the GPL. There is the icedtea project http://icedtea.classpath.org/ for example which provides a full GPLed release where all the binary blobs from openjdk not yet released under the GPL are replaced with code from GNU Classpath so that various GNU/Linux distribution can start shipping a OpenJDK variant right now: http://fedoraproject.org/wiki/Features/IcedTea http://lists.debian.org/debian-java/2007/08/msg00028.html Does anybody have some kind of overview page listing the remaining components and their replacement status in openjdk/icedtea? > 3. What should people - programmers (hobbyist, professional) adopt - > Open JDK or Sun JDK? Can we call one "better" than the other? Who is > Open JDK mainly targeted at? We can call the Sun JDK stable, but non-free and OpenJDK development, but free. So depending on your priorities one or the other is more fun to work with. > 4. Future plans for Open JDK and Sun JDK. I don't believe there is a concrete roadmap yet. But you can find some of the ideas for both at: http://tech.puredanger.com/java7 http://fitzsim.org/blog/?p=19 > 5. Which is the future? - Open JDK or Sun JDK If things go as planned it isn't "or", it is "and". See again the FAQ: http://www.sun.com/software/opensource/java/faq.jsp Q: Will Sun's commercial JDK releases be built from the open-source code? A: Yes, for the most part. Since there's some encumbered code in the JDK, Sun will continue to use that code in commercial releases until it's replaced by fully-functional open-source alternatives. In addition, Sun may deliver more differentiated commercial JDK products that address specific market needs in the future with these variants still built from the open-source code. So Sun JDK will be just one instance of OpenJDK. > I am not sure if this is the proper list, in that case, please point > me to the appropriate place. I shall really appreciate some insights > into all or some of the topics mentioned above. I think you miss a topic "The Unexpected". Various groups are doing all kind of unexpected (crazy!) things with the code now. See for example: http://www.infoq.com/news/2007/06/openjdk-hybrids Cheers, Mark From iris.clark at Sun.COM Wed Oct 3 12:49:17 2007 From: iris.clark at Sun.COM (Iris Garcia) Date: Wed, 3 Oct 2007 12:49:17 -0700 (PDT) Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <4703D9DF.7040309@sun.com> (message from Frances Ho on Wed, 03 Oct 2007 11:05:19 -0700) Message-ID: <200710031949.l93JnH9n008204@ribbit.SFBay.Sun.COM> Hi, Frances. > Question from Janet - was Joe aware of this? He is our rep on > conformance council. Was he at the mtg where they decided for > you to propose? Thanks. Yes. Talk to me off-line if you need more details. iris From Ray.Gans at Sun.COM Thu Oct 4 12:38:08 2007 From: Ray.Gans at Sun.COM (Ray Gans) Date: Thu, 04 Oct 2007 12:38:08 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <1191225537.3842.15.camel@dijkstra.wildebeest.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> Message-ID: On Oct 1, 2007, at 12:58 AM, Mark Wielaard wrote: > > I do have my doubts about this second part though. Is it really in the > interest of the openjdk project to have secret lists where proprietary > software is discussed without the rest of the community being able to > see, share and help out? The thing I like about OpenJDK is that it > is a > free software community, where all software and ideas are shared in > the > open. There are still of course the binary blobs and the jtreg suite, > but my understanding is that those will be liberated over time (as > icedtea and mauve have shown can already be done). Is the idea that > over > time the JCK will also become a proper part of OpenJDK under a free > license? > > Cheers, > > Mark You're correct Mark, private mailing lists are not really in the spirit of being open. But I wouldn't characterize this new private mailing list as "secret" inasmuch as its purpose is to comply with the confidentiality terms of the license. I think it's "a good thing" to have one place where all OpenJDK JCK licensees can chat together. I guess all Sun can do is to ask for understanding that the confidentiality terms were chosen to protect Sun's business concerns and not to restrict the OpenJDK community's involvement with conformance testing. As others have reported, making the JCK available to developers is a HUGE step for Sun. I am personally very pleased we've made this decision and I look forward to the JCK helping many participants in OpenJDK work more closely with each other to improve the technology and bring complete and conformant implementations onto platforms and environments that need it. As to whether the JCK will ever be open sourced, I think Mark Reinhold said it best: On Oct 1, 2007, at 5:59 PM, Mark Reinhold wrote > As a wise man once said, my crystal ball is very cloudy. -Ray From David.Herron at Sun.COM Fri Oct 5 15:40:38 2007 From: David.Herron at Sun.COM (David Herron) Date: Fri, 05 Oct 2007 15:40:38 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <1191266175.3842.72.camel@dijkstra.wildebeest.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> <470103BE.8050806@sun.com> <1191266175.3842.72.camel@dijkstra.wildebeest.org> Message-ID: <4706BD66.2020007@sun.com> Mark Wielaard wrote: > Hi David, > > On Mon, 2007-10-01 at 07:27 -0700, David Herron wrote: > >> Andrew John Hughes wrote: >> >>> On Monday 01 October 2007 08:58:57 Mark Wielaard wrote: >>> >>> >>>> This sound great. One idea for this is inviting Stuart Ballard (CCed). >>>> His japitools http://www.kaffe.org/~stuart/japi/ have been a great part >>>> of the communities conformance and compatibility drive. >>>> >>> Seconded; Stuart's tools have been invaluable during the development of GNU >>> Classpath and are equally applicable as general tools for ensuring binary API >>> compatabillity between releases. >>> >> We use some similar tools in-house. >> > So, how do they compare to japi-tools? How are they used? Are the > results of running the tools and the source available to the public? And > are they intended to become free software as part of openjdk? These are the tools http://www.jcp.org/en/resources/tdk Seems you need to be a JCP member to access some of those, however the javatest harness is opensource (as I'm sure you're aware) at http://jtharness.dev.java.net I haven't tried running either japitools or sigtest but on IRC you pointed me to this site http://sab39.netreach.com/Software/Japitools/42/ and I find the reports published there pretty nice and useful. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071005/f1bca475/attachment.html From mark at klomp.org Sun Oct 7 10:26:30 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 07 Oct 2007 19:26:30 +0200 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <4706BD66.2020007@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> <470103BE.8050806@sun.com> <1191266175.3842.72.camel@dijkstra.wildebeest.org> <4706BD66.2020007@sun.com> Message-ID: <1191777990.3118.36.camel@localhost.localdomain> Hi David, On Fri, 2007-10-05 at 15:40 -0700, David Herron wrote: > Mark Wielaard wrote: > > So, how do they compare to japi-tools? How are they used? Are the > > results of running the tools and the source available to the public? > > And are they intended to become free software as part of openjdk? > > These are the tools > http://www.jcp.org/en/resources/tdk > > Seems you need to be a JCP member to access some of those, however the > javatest harness is opensource (as I'm sure you're aware) at > http://jtharness.dev.java.net Nice. The Signature Test and the Spec Trac tools sound very interesting. And having the sample TCK under the GPL would encourage more TCKs under a free software license by default. So are these the tools, source code and guides that the Conformance team would maintain as part of OpenJDK? Are jtharness and jtreg currently part of the OpenJDK Quality Group projects? Thanks, Mark From David.Herron at Sun.COM Sun Oct 7 12:36:02 2007 From: David.Herron at Sun.COM (David Herron) Date: Sun, 07 Oct 2007 12:36:02 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <1191777990.3118.36.camel@localhost.localdomain> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> <470103BE.8050806@sun.com> <1191266175.3842.72.camel@dijkstra.wildebeest.org> <4706BD66.2020007@sun.com> <1191777990.3118.36.camel@localhost.localdomain> Message-ID: <47093522.2030600@sun.com> Mark Wielaard wrote: > Hi David, > > On Fri, 2007-10-05 at 15:40 -0700, David Herron wrote: > >> Mark Wielaard wrote: >> >>> So, how do they compare to japi-tools? How are they used? Are the >>> results of running the tools and the source available to the public? >>> And are they intended to become free software as part of openjdk? >>> >> These are the tools >> http://www.jcp.org/en/resources/tdk >> >> Seems you need to be a JCP member to access some of those, however the >> javatest harness is opensource (as I'm sure you're aware) at >> http://jtharness.dev.java.net >> > Nice. The Signature Test and the Spec Trac tools sound very interesting. > And having the sample TCK under the GPL would encourage more TCKs under > a free software license by default. So are these the tools, source code > and guides that the Conformance team would maintain as part of OpenJDK? > Are jtharness and jtreg currently part of the OpenJDK Quality Group > projects? > > Thanks, > > Mark > > Hi Mark, I cannot speak for their plans - as I said before, SQE != Conformance, and I'm in the SQE team. But thinking about and looking at this ... I'd say it would be a mistake to make those tools part of the OpenJDK project. There are TCK's other than for Java SE. I'm sure you have heard of Java ME and Java EE. These TDK tools are used by the whole Java ecosystem, not just the Java SE team. My thought is many of those tools would be useful as open source widgets, but not within the OpenJDK project. Maybe as part of the jtharness project? But at the end it's up to the team which makes those tools what they will do with them. FWIW on Friday while we were IRC'ing this thought came to mind (personal opinion) that if there is to be a hope for properly open source JSR's then the tools to create and manage a JSR and a TCK should be open source. But if this is to happen it is a JCP issue, not one for the OpenJDK project. As I understand it the OpenJDK project is about Sun opening our specific implementation of Java SE, and that the JCP is still managing the Java ecosystem. We did not "open source Java", we open sourced a specific Java SE implementation. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071007/a257b88e/attachment.html From Onno.Kluyt at Sun.COM Mon Oct 8 07:00:18 2007 From: Onno.Kluyt at Sun.COM (Onno Kluyt) Date: Mon, 08 Oct 2007 10:00:18 -0400 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <1191777990.3118.36.camel@localhost.localdomain> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <1191225537.3842.15.camel@dijkstra.wildebeest.org> <200710011241.27161.gnu_andrew@member.fsf.org> <470103BE.8050806@sun.com> <1191266175.3842.72.camel@dijkstra.wildebeest.org> <4706BD66.2020007@sun.com> <1191777990.3118.36.camel@localhost.localdomain> Message-ID: The tools at the JCP web site are an older version of what we use internally and of what is open sourced in the cqme project at Mobile & Embedded (https://cqme.dev.java.net/). We are looking into adding some more of our tools there. The suggestion of an GPL-ed sample TCK is an interesting one. Onno. On Oct 7, 2007, at 1:26 PM, Mark Wielaard wrote: > Hi David, > > On Fri, 2007-10-05 at 15:40 -0700, David Herron wrote: >> Mark Wielaard wrote: >>> So, how do they compare to japi-tools? How are they used? Are the >>> results of running the tools and the source available to the public? >>> And are they intended to become free software as part of openjdk? >> >> These are the tools >> http://www.jcp.org/en/resources/tdk >> >> Seems you need to be a JCP member to access some of those, however >> the >> javatest harness is opensource (as I'm sure you're aware) at >> http://jtharness.dev.java.net > > Nice. The Signature Test and the Spec Trac tools sound very > interesting. > And having the sample TCK under the GPL would encourage more TCKs > under > a free software license by default. So are these the tools, source > code > and guides that the Conformance team would maintain as part of > OpenJDK? > Are jtharness and jtreg currently part of the OpenJDK Quality Group > projects? > > Thanks, > > Mark > From Xiomara.Jayasena at Sun.COM Mon Oct 8 10:16:27 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Mon, 08 Oct 2007 10:16:27 -0700 Subject: JDK 7 moving to mercurial -- svn repositories Message-ID: <470A65EB.2040009@Sun.COM> Hi, As many of you know the jdk 7 workspaces will be moving from Teamware to Mercurial. As of now we host svn repositories here: https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ and here: https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ Once JDK 7 moves to Mercurial we would like to know whether there is a need to keep the svn repositories out there and if so forever? overlap for sometime? I am trying to figure out what would be best for most people. Thanks, -Xiomara From robilad at kaffe.org Tue Oct 9 05:17:01 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 09 Oct 2007 14:17:01 +0200 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <470A65EB.2040009@Sun.COM> References: <470A65EB.2040009@Sun.COM> Message-ID: <470B713D.40003@kaffe.org> Xiomara.Jayasena at Sun.COM wrote: > > Hi, > > As many of you know the jdk 7 workspaces will be moving from Teamware to > Mercurial. As of now we host svn repositories here: > https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ > and > here: > https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ > > Once JDK 7 moves to Mercurial we would like to know whether there is a > need to keep the svn repositories out there and if so forever? overlap > for sometime? I am trying to figure out what would be best for most > people. I don't think there is a need to keep them around, as you have the zip-ed/tar-ed source code downloads for people just wanting to fetch and build the 'latest' build, while a source code repository, for me at least, is the place where the actual work is happening. And there can be only one of those. ;) cheers, dalibor topic From mcconnell at dpml.net Tue Oct 9 09:20:08 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Wed, 10 Oct 2007 01:50:08 +0930 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <470B713D.40003@kaffe.org> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> Message-ID: <1191946808.12606.15.camel@gloria> On Tue, 2007-10-09 at 14:17 +0200, Dalibor Topic wrote: > Xiomara.Jayasena at Sun.COM wrote: > > > > Hi, > > > > As many of you know the jdk 7 workspaces will be moving from Teamware to > > Mercurial. As of now we host svn repositories here: > > https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ > > and > > here: > > https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ > > > > Once JDK 7 moves to Mercurial we would like to know whether there is a > > need to keep the svn repositories out there and if so forever? overlap > > for sometime? I am trying to figure out what would be best for most > > people. > > I don't think there is a need to keep them around, as you have the > zip-ed/tar-ed source code downloads for people just wanting to fetch and > build the 'latest' build, while a source code repository, for me at > least, is the place where the actual work is happening. > > And there can be only one of those. ;) I agree completely. Backups of legacy to take care of the past and move on to Mercurial for the future. Cheers, Steve. From Xiomara.Jayasena at Sun.COM Tue Oct 9 12:57:14 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Tue, 09 Oct 2007 12:57:14 -0700 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <1191946808.12606.15.camel@gloria> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> Message-ID: <470BDD1A.4060908@Sun.COM> Thank you for your feeback -- these responses along with others I have received seem to be in the same line of thought. So it is OK to do away with the svn repositories once the Mercurial ones are up. -Xiomara Stephen J. McConnell wrote: >On Tue, 2007-10-09 at 14:17 +0200, Dalibor Topic wrote: > > >>Xiomara.Jayasena at Sun.COM wrote: >> >> >>>Hi, >>> >>>As many of you know the jdk 7 workspaces will be moving from Teamware to >>>Mercurial. As of now we host svn repositories here: >>>https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ >>>and >>>here: >>>https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ >>> >>>Once JDK 7 moves to Mercurial we would like to know whether there is a >>>need to keep the svn repositories out there and if so forever? overlap >>>for sometime? I am trying to figure out what would be best for most >>>people. >>> >>> >>I don't think there is a need to keep them around, as you have the >>zip-ed/tar-ed source code downloads for people just wanting to fetch and >>build the 'latest' build, while a source code repository, for me at >>least, is the place where the actual work is happening. >> >>And there can be only one of those. ;) >> >> > >I agree completely. > >Backups of legacy to take care of the past and move on to Mercurial for >the future. > >Cheers, Steve. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071009/905f53c9/attachment.html From robilad at kaffe.org Tue Oct 9 14:19:50 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 09 Oct 2007 23:19:50 +0200 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <470BDD1A.4060908@Sun.COM> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> Message-ID: <470BF076.3000009@kaffe.org> Xiomara.Jayasena at Sun.COM wrote: > > Thank you for your feeback -- these responses along with others I have > received seem to be in the same line of thought. So it is OK to do away > with the svn repositories once the Mercurial ones are up. > > -Xiomara Thanks, Xiomara. And as a bit of encouragement to the other responders, it's OK to post your feedback to discuss, too. ;) cheers, dalibor topic From arnold.schwaighofer at gmail.com Wed Oct 10 00:55:53 2007 From: arnold.schwaighofer at gmail.com (Arnold Schwaighofer) Date: Wed, 10 Oct 2007 09:55:53 +0200 Subject: Project proposal: Multi-Language VM Message-ID: <6C8B8E53-7368-476D-B824-B316925AFAA4@gmail.com> Hi John, my master thesis will be to implement tail call optimization in the client compiler. And I would be looking forward to the mlvm project. As a fan of functional programming style i would also love to see closures et al. come to the java platform. regards arnold > Hello world. I propose a new OpenJDK project[1], > the Multi-Language VM, to be abbreviated "mlvm", > and to be sponsored by the HotSpot group[2]. > > This project will be open for prototyping > JVM features aimed at efficiently supporting > languages other than Java. > > The emphasis will be on completing the existing > bytecode and execution architecture with general > purpose extensions, as opposed to a new feature > for just one language, or adjoining an unrelated > new execution model. > > The emphasis will also be on work which removes > "pain points" already observed by implementors > of successful or influential languages, as opposed > to more speculative work on unproven features or > niche languages. > > Virtual machines produced by this project will > be standards-conforming, in that they will not change > the meaning or behavior of existing Java classes > and classfile formats. They may define variations > or extensions of the class format, or new kinds of > objects, whose meaning and behavior are beyond > the scope of current Java and JVM specifications. > > However, these extended codes and data structures > will interoperate as much as possible with Java objects. > > In addition, as a way of delimiting separate prototyping > efforts, each new feature will come with a switch which > turns it off, and that switch will be "off" by default. > This is the approach used in the Kitchen Sink Language > project.[3] > > This proposal refines and completes a partial proposal > I sent earlier this year to the HotSpot project, > a proposal for a "Kitchen Sink VM"[4]. The present > proposal is more specifically directed at supporting > new languages (i.e., those languages which are > new to the JVM). > > Here are some examples of features that could be > prototyped in this project, if developers were found > who are willing and able: > > - tail calls and tail recursion [5] > - continuations and coroutines [6] > - tuples and value-oriented types [7] > - lightweight method objects [8] > - runtime support for closures [9] > - invokedynamic [10] > > Prototyping for JSR 292[11] is likely to occur as > a part of this project. Note that none of the above > suggested features is specific to any single language. > > As the current OpenJDK Project guidelines request, > please send followups to the discussion list.[12] > > Thanks very much for your attention to this matter, > > -- John Rose > http://blogs.sun.com/jrose/ > > [1] http://openjdk.java.net/projects/ > [2] http://openjdk.java.net/groups/hotspot/ > [3] http://ksl.dev.java.net/ (Kitchen Sink Language) > [4] http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-July/ > 000091.html (Kitchen Sink VM) > [5] http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm > [6] http://lambda-the-ultimate.org/node/1002 (Continuations for Java) > [7] http://blogs.sun.com/jrose/entry/tuples_in_the_vm > [8] http://groups.google.com/group/jvm-languages/t/dbc3a4a382868904 > (Lightweight Methods) > [9] http://www.javac.info/ (Java Closures) > [10] http://groups.google.com/group/jvm-languages/web/implementation- > of-multimethods-in-jvm-languages > [11] http://jcp.org/en/jsr/detail?id=292#2 (Original JSR 292 request) > [12] http://mail.openjdk.java.net/mailman/listinfo/discuss From mr at sun.com Thu Oct 11 10:41:05 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 11 Oct 2007 10:41:05 -0700 Subject: Publishing code reviews Message-ID: <20071011174105.6B0C2625A@eggemoggin.niobe.net> One of the engineering practices that's served the JDK development team well for many years now is that of peer-based code reviews. In mainline JDK development at least one review is required for every code change, and two or more are needed as release milestones approach. Reviews are most often performed with the help of a tool called "webrev", which basically diffs two source trees and generates a pile of HTML that you can view in a browser (sample: [1]). webrev was originally written by the Solaris team; lately it's been revised and extended [2] to support Mercurial and Subversion in addition to the old internal TeamWare SCM. A lot of the e-mail that JDK developers read and write is, naturally, about code reviews. It's not exactly convenient to attach webrevs to e-mail messages, so people typically either copy them to a directory published by a private web server and send the URL around, or they copy them over to an NFS-exported filesystem and send a long pathname (and cross their fingers if a potential reviewer is far away network-wise). The bug here, of course, is that these publication methods don't make code reviews visible on the open web, and this is one reason that most JDK developers have thus far been reluctant to move more of their e-mail traffic onto the public openjdk.java.net mailing lists. So: How should we solve this problem in a way that works for all JDK contributors, whether or not they work for Sun? We could build something slick and fancy, like Google's Mondrian [3], but I think it's relatively more important to get something up quickly and work on improving it later. A more expedient solution would be to construct something like the OpenSolaris code-review site [4,5], where contributors can use rsync, scp, and sftp (all via SSH) to upload webrevs to temporary storage on a public server. SSH keys will ultimately be required in order to push changesets into the public Mercurial repositories, so contributors will need to create and register SSH keys anyway, and the code-review site can easily leverage the same underlying infrastructure. Comments? Alternatives? - Mark [1] http://cr.opensolaris.org/~dp/i2o-del/ [2] http://blogs.sun.com/dp/entry/webrev_revised [3] http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html [4] http://cr.opensolaris.org/ [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work From Dmitri.Trembovetski at Sun.COM Thu Oct 11 11:01:48 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 11:01:48 -0700 Subject: Publishing code reviews In-Reply-To: <20071011174105.6B0C2625A@eggemoggin.niobe.net> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> Message-ID: <470E650C.9050906@Sun.COM> Hi Mark, what about moving one of our our internal code review tools to an outside server? Like the one the client team uses - the 'code review robot'. You submit the code review either via email or web page. The webrev is then hosted on the "robot system" so the reviewers can see it. The communication between the reviewers happens via email, the robot is CC-ed. The tool supports multiple fix revisions, approvals, etc. It will probably need some polishing up - since currently there's no authentication, for example, but it's been used by many people for a long time and is found to be very convenient if not as flashy as Mondrian and some ajaxy tools.. Thanks, Dmitri Mark Reinhold wrote: > One of the engineering practices that's served the JDK development team > well for many years now is that of peer-based code reviews. In mainline > JDK development at least one review is required for every code change, > and two or more are needed as release milestones approach. > > Reviews are most often performed with the help of a tool called "webrev", > which basically diffs two source trees and generates a pile of HTML that > you can view in a browser (sample: [1]). webrev was originally written > by the Solaris team; lately it's been revised and extended [2] to support > Mercurial and Subversion in addition to the old internal TeamWare SCM. > > A lot of the e-mail that JDK developers read and write is, naturally, > about code reviews. It's not exactly convenient to attach webrevs to > e-mail messages, so people typically either copy them to a directory > published by a private web server and send the URL around, or they copy > them over to an NFS-exported filesystem and send a long pathname (and > cross their fingers if a potential reviewer is far away network-wise). > > The bug here, of course, is that these publication methods don't make > code reviews visible on the open web, and this is one reason that most > JDK developers have thus far been reluctant to move more of their e-mail > traffic onto the public openjdk.java.net mailing lists. > > So: How should we solve this problem in a way that works for all JDK > contributors, whether or not they work for Sun? > > We could build something slick and fancy, like Google's Mondrian [3], > but I think it's relatively more important to get something up quickly > and work on improving it later. > > A more expedient solution would be to construct something like the > OpenSolaris code-review site [4,5], where contributors can use rsync, > scp, and sftp (all via SSH) to upload webrevs to temporary storage on > a public server. SSH keys will ultimately be required in order to push > changesets into the public Mercurial repositories, so contributors will > need to create and register SSH keys anyway, and the code-review site > can easily leverage the same underlying infrastructure. > > Comments? Alternatives? > > - Mark > > > [1] http://cr.opensolaris.org/~dp/i2o-del/ > [2] http://blogs.sun.com/dp/entry/webrev_revised > [3] http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html > [4] http://cr.opensolaris.org/ > [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work From tobrien at discursive.com Thu Oct 11 11:04:38 2007 From: tobrien at discursive.com (Tim O'Brien) Date: Thu, 11 Oct 2007 13:04:38 -0500 Subject: Publishing code reviews In-Reply-To: <20071011174105.6B0C2625A@eggemoggin.niobe.net> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> Message-ID: <7260cf030710111104p49171efcrc8eac7f300e0e67@mail.gmail.com> If you have a process that's working well internally, don't change it. Clone what works internally and move it out into the open. I'm sure that once people see it, you'll end up with a bunch of contributors from outside of Sun coming up with various unsolicited improvements. (I'd be surprised if you don't end up with something similar to Mondrian in short order). Maybe just create another mailing list and adopt the sort of standard you see in projects like Jakarta Commons or Codehaus Mojo where email subjects are prefixed with a string like [REVIEW-2324]. If it the email list is public, people will have the choice to view it in something like Nabble or subscribe directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071011/a7548b82/attachment.html From Phil.Race at Sun.COM Thu Oct 11 11:09:08 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 11 Oct 2007 11:09:08 -0700 Subject: Publishing code reviews In-Reply-To: <470E650C.9050906@Sun.COM> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> <470E650C.9050906@Sun.COM> Message-ID: <470E66C4.7060801@sun.com> Dmitri beat me to it .. 'robot' also archives the webrevs and the email exchange .. so even the rest of the world who really didn't want to see every set of comments on every bug can always go look .. It also generates approval emails with nicely formatted putback comments. I was chatting yesterday with an external developer who saw something like this as the next step after mercurial. BTW Mark wrote : > In mainline > JDK development at least one review is required for every code change, > and two or more are needed as release milestones approach. In the client groups (2D, AWT, Swing etc) we always require two reviews, except for the most trivial and low-risk changes (updating a test and the like, which optionally may only require one review). I expect we will continue to maintain that standard. -phil. Dmitri Trembovetski wrote: > > Hi Mark, > > what about moving one of our our internal code review tools > to an outside server? > > Like the one the client team uses - the 'code review robot'. > You submit the code review either via email or web page. > The webrev is then hosted on the "robot system" so the reviewers > can see it. > > The communication between the reviewers happens via email, the > robot is CC-ed. The tool supports multiple fix revisions, > approvals, etc. > > It will probably need some polishing up - since currently > there's no authentication, for example, but it's been used > by many people for a long time and is found to be very > convenient if not as flashy as Mondrian and some ajaxy tools.. > > Thanks, > Dmitri > > > Mark Reinhold wrote: >> One of the engineering practices that's served the JDK development team >> well for many years now is that of peer-based code reviews. In mainline >> JDK development at least one review is required for every code change, >> and two or more are needed as release milestones approach. >> >> Reviews are most often performed with the help of a tool called "webrev", >> which basically diffs two source trees and generates a pile of HTML that >> you can view in a browser (sample: [1]). webrev was originally written >> by the Solaris team; lately it's been revised and extended [2] to support >> Mercurial and Subversion in addition to the old internal TeamWare SCM. >> >> A lot of the e-mail that JDK developers read and write is, naturally, >> about code reviews. It's not exactly convenient to attach webrevs to >> e-mail messages, so people typically either copy them to a directory >> published by a private web server and send the URL around, or they copy >> them over to an NFS-exported filesystem and send a long pathname (and >> cross their fingers if a potential reviewer is far away network-wise). >> >> The bug here, of course, is that these publication methods don't make >> code reviews visible on the open web, and this is one reason that most >> JDK developers have thus far been reluctant to move more of their e-mail >> traffic onto the public openjdk.java.net mailing lists. >> >> So: How should we solve this problem in a way that works for all JDK >> contributors, whether or not they work for Sun? >> >> We could build something slick and fancy, like Google's Mondrian [3], >> but I think it's relatively more important to get something up quickly >> and work on improving it later. >> >> A more expedient solution would be to construct something like the >> OpenSolaris code-review site [4,5], where contributors can use rsync, >> scp, and sftp (all via SSH) to upload webrevs to temporary storage on >> a public server. SSH keys will ultimately be required in order to push >> changesets into the public Mercurial repositories, so contributors will >> need to create and register SSH keys anyway, and the code-review site >> can easily leverage the same underlying infrastructure. >> >> Comments? Alternatives? >> >> - Mark >> >> >> [1] http://cr.opensolaris.org/~dp/i2o-del/ >> [2] http://blogs.sun.com/dp/entry/webrev_revised >> [3] >> http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html >> [4] http://cr.opensolaris.org/ >> [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work From Andreas.Sterbenz at Sun.COM Thu Oct 11 11:20:09 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 11 Oct 2007 11:20:09 -0700 Subject: Publishing code reviews In-Reply-To: <20071011174105.6B0C2625A@eggemoggin.niobe.net> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> Message-ID: <470E6959.7090709@sun.com> Mark Reinhold wrote: > > We could build something slick and fancy, like Google's Mondrian [3], > but I think it's relatively more important to get something up quickly > and work on improving it later. > > A more expedient solution would be to construct something like the > OpenSolaris code-review site [4,5], where contributors can use rsync, > scp, and sftp (all via SSH) to upload webrevs to temporary storage on > a public server. SSH keys will ultimately be required in order to push > changesets into the public Mercurial repositories, so contributors will > need to create and register SSH keys anyway, and the code-review site > can easily leverage the same underlying infrastructure. I think it is important that we get something in place soon (weeks). In the Modules project we have been facing the issue of not being able to publicly post webrevs for some time. I consider the solution used by the Solaris team perfectly adequate. We can always upgrade to a better solution later on. Andreas. From Dmitri.Trembovetski at Sun.COM Thu Oct 11 11:35:02 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 11:35:02 -0700 Subject: Publishing code reviews In-Reply-To: <470E650C.9050906@Sun.COM> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> <470E650C.9050906@Sun.COM> Message-ID: <470E6CD6.90105@Sun.COM> Dmitri Trembovetski wrote: > > Hi Mark, > > what about moving one of our our internal code review tools > to an outside server? > > Like the one the client team uses - the 'code review robot'. > You submit the code review either via email or web page. > The webrev is then hosted on the "robot system" so the reviewers > can see it. > > The communication between the reviewers happens via email, the > robot is CC-ed. The tool supports multiple fix revisions, > approvals, etc. > > It will probably need some polishing up - since currently > there's no authentication, for example, but it's been used As for authentication, we could make it available only to those who have the "proper" accounts - we'd have to do that anyway for hg access, right? At least that would work until we find time to add authentication to the tool itself. Andreas Sterbenz wrote: > I consider the solution used by the Solaris team perfectly adequate. > We can always upgrade to a better solution later on. Those who had worked with this tool would find what OpenSolaris has not at all adequate.. Thanks, Dmitri > by many people for a long time and is found to be very > convenient if not as flashy as Mondrian and some ajaxy tools.. > > Thanks, > Dmitri > > > Mark Reinhold wrote: >> One of the engineering practices that's served the JDK development team >> well for many years now is that of peer-based code reviews. In mainline >> JDK development at least one review is required for every code change, >> and two or more are needed as release milestones approach. >> >> Reviews are most often performed with the help of a tool called "webrev", >> which basically diffs two source trees and generates a pile of HTML that >> you can view in a browser (sample: [1]). webrev was originally written >> by the Solaris team; lately it's been revised and extended [2] to support >> Mercurial and Subversion in addition to the old internal TeamWare SCM. >> >> A lot of the e-mail that JDK developers read and write is, naturally, >> about code reviews. It's not exactly convenient to attach webrevs to >> e-mail messages, so people typically either copy them to a directory >> published by a private web server and send the URL around, or they copy >> them over to an NFS-exported filesystem and send a long pathname (and >> cross their fingers if a potential reviewer is far away network-wise). >> >> The bug here, of course, is that these publication methods don't make >> code reviews visible on the open web, and this is one reason that most >> JDK developers have thus far been reluctant to move more of their e-mail >> traffic onto the public openjdk.java.net mailing lists. >> >> So: How should we solve this problem in a way that works for all JDK >> contributors, whether or not they work for Sun? >> >> We could build something slick and fancy, like Google's Mondrian [3], >> but I think it's relatively more important to get something up quickly >> and work on improving it later. >> >> A more expedient solution would be to construct something like the >> OpenSolaris code-review site [4,5], where contributors can use rsync, >> scp, and sftp (all via SSH) to upload webrevs to temporary storage on >> a public server. SSH keys will ultimately be required in order to push >> changesets into the public Mercurial repositories, so contributors will >> need to create and register SSH keys anyway, and the code-review site >> can easily leverage the same underlying infrastructure. >> >> Comments? Alternatives? >> >> - Mark >> >> >> [1] http://cr.opensolaris.org/~dp/i2o-del/ >> [2] http://blogs.sun.com/dp/entry/webrev_revised >> [3] >> http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html >> [4] http://cr.opensolaris.org/ >> [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work From Andreas.Sterbenz at Sun.COM Thu Oct 11 11:40:43 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 11 Oct 2007 11:40:43 -0700 Subject: Publishing code reviews In-Reply-To: <470E6CD6.90105@Sun.COM> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> <470E650C.9050906@Sun.COM> <470E6CD6.90105@Sun.COM> Message-ID: <470E6E2B.7050901@sun.com> > Andreas Sterbenz wrote: > > I consider the solution used by the Solaris team perfectly adequate. > > We can always upgrade to a better solution later on. > > Those who had worked with this tool would find what OpenSolaris > has not at all adequate.. If we can deliver the solution you have in mind "soon", then by all means we should do that. However, if we cannot do that, we should not prevent a more basic system from being used in the meantime. Andreas. From mr at sun.com Thu Oct 11 11:47:24 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 11 Oct 2007 11:47:24 -0700 Subject: Publishing code reviews In-Reply-To: dmitri.trembovetski@sun.com; Thu, 11 Oct 2007 11:01:48 PDT; <470E650C.9050906@Sun.COM> Message-ID: <20071011184724.89E9F625A@eggemoggin.niobe.net> > Date: Thu, 11 Oct 2007 11:01:48 -0700 > From: dmitri.trembovetski at sun.com > what about moving one of our our internal code review tools > to an outside server? > > Like the one the client team uses - the 'code review robot'. > You submit the code review either via email or web page. > The webrev is then hosted on the "robot system" so the reviewers > can see it. > > The communication between the reviewers happens via email, the > robot is CC-ed. The tool supports multiple fix revisions, > approvals, etc. > > It will probably need some polishing up - since currently > there's no authentication, for example, but it's been used > by many people for a long time and is found to be very > convenient if not as flashy as Mondrian and some ajaxy tools.. A fine idea, but I see two problems. One is the polishing-up bit -- that's more work than setting up a simple rsync-driven web server. It'd be great for the robot to be made publicly available eventually, but right now I think expedience demands simplicity. The other is that some JDK developers, well, just don't like the robot. So we'd need to either convince people to use it anyway, which would take time if it's possible at all, or else provide something simpler ... like the OpenSolaris service. If we do create an OpenSolaris-style code-review server then we should certainly arrange for the robot to publish webrevs there. That can't be hard. - Mark From Joe.Darcy at Sun.COM Thu Oct 11 11:51:25 2007 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 11 Oct 2007 11:51:25 -0700 Subject: Publishing code reviews In-Reply-To: <470E66C4.7060801@sun.com> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> <470E650C.9050906@Sun.COM> <470E66C4.7060801@sun.com> Message-ID: <470E70AD.3030708@sun.com> Phil Race wrote: > Dmitri beat me to it .. > > 'robot' also archives the webrevs and the email exchange .. so > even the rest of the world who really didn't want to see every > set of comments on every bug can always go look .. > It also generates approval emails with nicely formatted putback comments. > I was chatting yesterday with an external developer who saw > something like this as the next step after mercurial. Yes, we've also used the robot on the javac team. It is easy to use and helps manage a large flow of review requests. The archival aspect is important too. -Joe > BTW Mark wrote : > > > In mainline > > JDK development at least one review is required for every code change, > > and two or more are needed as release milestones approach. > > In the client groups (2D, AWT, Swing etc) we always require two reviews, > except for the most trivial and low-risk changes (updating a test and > the like, > which optionally may only require one review). I expect we will continue > to maintain that standard. > > -phil. > > > Dmitri Trembovetski wrote: >> >> Hi Mark, >> >> what about moving one of our our internal code review tools >> to an outside server? >> >> Like the one the client team uses - the 'code review robot'. >> You submit the code review either via email or web page. >> The webrev is then hosted on the "robot system" so the reviewers >> can see it. >> >> The communication between the reviewers happens via email, the >> robot is CC-ed. The tool supports multiple fix revisions, >> approvals, etc. >> >> It will probably need some polishing up - since currently >> there's no authentication, for example, but it's been used >> by many people for a long time and is found to be very >> convenient if not as flashy as Mondrian and some ajaxy tools.. >> >> Thanks, >> Dmitri >> >> >> Mark Reinhold wrote: >>> One of the engineering practices that's served the JDK development team >>> well for many years now is that of peer-based code reviews. In >>> mainline >>> JDK development at least one review is required for every code change, >>> and two or more are needed as release milestones approach. >>> >>> Reviews are most often performed with the help of a tool called >>> "webrev", >>> which basically diffs two source trees and generates a pile of HTML >>> that >>> you can view in a browser (sample: [1]). webrev was originally written >>> by the Solaris team; lately it's been revised and extended [2] to >>> support >>> Mercurial and Subversion in addition to the old internal TeamWare SCM. >>> >>> A lot of the e-mail that JDK developers read and write is, naturally, >>> about code reviews. It's not exactly convenient to attach webrevs to >>> e-mail messages, so people typically either copy them to a directory >>> published by a private web server and send the URL around, or they copy >>> them over to an NFS-exported filesystem and send a long pathname (and >>> cross their fingers if a potential reviewer is far away network-wise). >>> >>> The bug here, of course, is that these publication methods don't make >>> code reviews visible on the open web, and this is one reason that most >>> JDK developers have thus far been reluctant to move more of their >>> e-mail >>> traffic onto the public openjdk.java.net mailing lists. >>> >>> So: How should we solve this problem in a way that works for all JDK >>> contributors, whether or not they work for Sun? >>> >>> We could build something slick and fancy, like Google's Mondrian [3], >>> but I think it's relatively more important to get something up quickly >>> and work on improving it later. >>> >>> A more expedient solution would be to construct something like the >>> OpenSolaris code-review site [4,5], where contributors can use rsync, >>> scp, and sftp (all via SSH) to upload webrevs to temporary storage on >>> a public server. SSH keys will ultimately be required in order to push >>> changesets into the public Mercurial repositories, so contributors will >>> need to create and register SSH keys anyway, and the code-review site >>> can easily leverage the same underlying infrastructure. >>> >>> Comments? Alternatives? >>> >>> - Mark >>> >>> >>> [1] http://cr.opensolaris.org/~dp/i2o-del/ >>> [2] http://blogs.sun.com/dp/entry/webrev_revised >>> [3] >>> http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html >>> [4] http://cr.opensolaris.org/ >>> [5] http://blogs.sun.com/dp/entry/cr_opensolaris_org_a_work From Dmitri.Trembovetski at Sun.COM Thu Oct 11 12:02:59 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 12:02:59 -0700 Subject: Publishing code reviews In-Reply-To: <20071011184724.89E9F625A@eggemoggin.niobe.net> References: <20071011184724.89E9F625A@eggemoggin.niobe.net> Message-ID: <470E7363.70508@Sun.COM> Mark Reinhold wrote: >> Date: Thu, 11 Oct 2007 11:01:48 -0700 >> From: dmitri.trembovetski at sun.com > >> what about moving one of our our internal code review tools >> to an outside server? >> >> Like the one the client team uses - the 'code review robot'. >> You submit the code review either via email or web page. >> The webrev is then hosted on the "robot system" so the reviewers >> can see it. >> >> The communication between the reviewers happens via email, the >> robot is CC-ed. The tool supports multiple fix revisions, >> approvals, etc. >> >> It will probably need some polishing up - since currently >> there's no authentication, for example, but it's been used >> by many people for a long time and is found to be very >> convenient if not as flashy as Mondrian and some ajaxy tools.. > > A fine idea, but I see two problems. > > One is the polishing-up bit -- that's more work than setting up a simple > rsync-driven web server. It'd be great for the robot to be made publicly > available eventually, but right now I think expedience demands > simplicity. If that's the case, just don't do any polishing up for now. It would take some effort to migrate the system to another machine (Igor Kushnirsky would know how much effort that would take). But the robot - especially it's built-in archive feature (all review-related conversations are archived, along with webrevs) - proved invaluable. > The other is that some JDK developers, well, just don't like the robot. > So we'd need to either convince people to use it anyway, which would take > time if it's possible at all, or else provide something simpler ... like > the OpenSolaris service. What about the JDK developers who would not like the OpenSolaris service? I would wager that they will be the majority =) > If we do create an OpenSolaris-style code-review server then we should > certainly arrange for the robot to publish webrevs there. That can't be > hard. Yes, that would be good in any case. Would we need to somehow filter out the webrevs which contain closed sources? Thanks, Dmitri From roman.kennke at aicas.com Thu Oct 11 12:08:17 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 11 Oct 2007 21:08:17 +0200 Subject: Publishing code reviews In-Reply-To: <470E650C.9050906@Sun.COM> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> <470E650C.9050906@Sun.COM> Message-ID: <1192129697.2826.28.camel@mercury> Hi, > Like the one the client team uses - the 'code review robot'. > You submit the code review either via email or web page. > The webrev is then hosted on the "robot system" so the reviewers > can see it. > > The communication between the reviewers happens via email, the > robot is CC-ed. The tool supports multiple fix revisions, > approvals, etc. The robot thing sounds like a good tool for that job. And, good idea to move code review to public. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From mr at sun.com Thu Oct 11 15:54:25 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 11 Oct 2007 15:54:25 -0700 Subject: Publishing code reviews In-Reply-To: dmitri.trembovetski@sun.com; Thu, 11 Oct 2007 12:02:59 PDT; <470E7363.70508@Sun.COM> Message-ID: <20071011225425.6A687625A@eggemoggin.niobe.net> > Date: Thu, 11 Oct 2007 12:02:59 -0700 > From: dmitri.trembovetski at sun.com > ... > > It would take some effort to migrate the system to another > machine (Igor Kushnirsky would know how much effort that > would take). That would be good to know. Would Igor (or someone) have the time to do this migration anytime soon? > But the robot - especially it's built-in archive > feature (all review-related conversations are archived, > along with webrevs) - proved invaluable. I can believe that -- but do you want to force it on the entire team? > What about the JDK developers who would not like the OpenSolaris > service? I would wager that they will be the majority =) That could be, but my sense is that there's a significant minority that doesn't like the robot. >> If we do create an OpenSolaris-style code-review server then we should >> certainly arrange for the robot to publish webrevs there. That can't be >> hard. > > Yes, that would be good in any case. The OpenSolaris-style code-review service is essentially a strict subset of the robot service. Until the robot is migrated to an external server (and likely even after that) we can easily arrange for it to publish webrevs on the code-review server. The robot only sends e-mail messages to specific reviewers, not to mailing lists. That's fine internally, but we should likely also have the robot cc: e-mails to the appropriate public lists so that anyone can read the review traffic. These need not be the foo-dev lists; we could set up a parallel set of, say, foo-review lists. Does that make sense? > Would we need to somehow filter out the webrevs which > contain closed sources? Yes. That's a Sun-internal problem, though, so let's discuss it internally. - Mark From tobrien at discursive.com Thu Oct 11 16:02:17 2007 From: tobrien at discursive.com (Tim O'Brien) Date: Thu, 11 Oct 2007 18:02:17 -0500 Subject: Publishing code reviews In-Reply-To: <20071011225425.6A687625A@eggemoggin.niobe.net> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> Message-ID: <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> On 10/11/07, Mark Reinhold wrote: > > > Would we need to somehow filter out the webrevs which > > contain closed sources? > > Yes. That's a Sun-internal problem, though, so let's discuss it > internally. That's interesting, what sort of code is closed? Is there ever going to be a case where a webrev contains certain sections that are public and certain sections that are private? since you mentioned it on a public list, could you give us a sense of what the public is missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071011/beb9a81e/attachment.html From Dmitri.Trembovetski at Sun.COM Thu Oct 11 16:17:09 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 16:17:09 -0700 Subject: Publishing code reviews In-Reply-To: <20071011225425.6A687625A@eggemoggin.niobe.net> References: <20071011225425.6A687625A@eggemoggin.niobe.net> Message-ID: <470EAEF5.2060002@Sun.COM> Mark Reinhold wrote: >> But the robot - especially it's built-in archive >> feature (all review-related conversations are archived, >> along with webrevs) - proved invaluable. > > I can believe that -- but do you want to force it on the entire team? *I* would. It's for their own good! =) >>> If we do create an OpenSolaris-style code-review server then we should >>> certainly arrange for the robot to publish webrevs there. That can't be >>> hard. >> Yes, that would be good in any case. > > The OpenSolaris-style code-review service is essentially a strict subset > of the robot service. Until the robot is migrated to an external server > (and likely even after that) we can easily arrange for it to publish > webrevs on the code-review server. That would be enough for the internal people who want to include external folks into the code reviews. Currently we have to send them zipped webrev separately since they can't access the internal url. Actually, the external folks can easily submit the code reviews even without Robot being moved to the outside system: they can just send an email with specially constructed subject to the robot with webrev archive attached - this is one of the Robot options for submitting the reviews. Another being the web page (which I think most folks here use). > The robot only sends e-mail messages to specific reviewers, not to > mailing lists. That's fine internally, but we should likely also have > the robot cc: e-mails to the appropriate public lists so that anyone can > read the review traffic. These need not be the foo-dev lists; we could > set up a parallel set of, say, foo-review lists. I guess it wouldn't hurt, but we don't do anything like that internally because most people don't care much about other's code reviews - there's enough traffic already. If they do, they're the reviewers =) And, the Robot generates a page with all current code reviews for particular team listed, so anyone can just go ahead and browse the archived conversations. Similar pages exist for each team member. Wouldn't that be enough (providing we do move robot to the outside)? If we were all fancy (and had time) we could add rss/atom feeds to such pages. Thanks, Dmitri From Peter.Kessler at Sun.COM Thu Oct 11 16:26:16 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 11 Oct 2007 16:26:16 -0700 Subject: Publishing code reviews In-Reply-To: <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> Message-ID: <470EB118.1080805@Sun.COM> Tim O'Brien wrote: > > > On 10/11/07, *Mark Reinhold* > wrote: > > > Would we need to somehow filter out the webrevs which > > contain closed sources? > > Yes. That's a Sun-internal problem, though, so let's discuss it > internally. > > > > That's interesting, what sort of code is closed? Is there ever going > to be a case where a webrev contains certain sections that are public > and certain sections that are private? since you mentioned it on a > public list, could you give us a sense of what the public is missing? Think of the code we can't release because of the encumberances. If we have to make changes in that code, we need to get reviews, but we can't ask the community for help with those reviews. Clearly the less code we have that we can't put in the open the better. But as long as that set is non-empty, it's something we have to deal with, internally. ... peter From tobrien at discursive.com Thu Oct 11 16:38:16 2007 From: tobrien at discursive.com (Tim O'Brien) Date: Thu, 11 Oct 2007 18:38:16 -0500 Subject: Publishing code reviews In-Reply-To: <470EB118.1080805@Sun.COM> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> Message-ID: <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> On 10/11/07, Peter B. Kessler wrote: > > Tim O'Brien wrote: > > > > > > > On 10/11/07, *Mark Reinhold* > wrote: > > > > > Would we need to somehow filter out the webrevs which > > > contain closed sources? > > > > Yes. That's a Sun-internal problem, though, so let's discuss it > > internally. > > > > > > > > That's interesting, what sort of code is closed? Is there ever going > > to be a case where a webrev contains certain sections that are public > > and certain sections that are private? since you mentioned it on a > > public list, could you give us a sense of what the public is missing? > > Think of the code we can't release because of the encumberances. > If we have to make changes in that code, we need to get reviews, > but we can't ask the community for help with those reviews. > > Clearly the less code we have that we can't put in the open the > better. But as long as that set is non-empty, it's something we > have to deal with, internally. Ok, so just to clear it up for the non-Sun folks this would be things like the font rasterization stuff that is still encumbered. Ideally the encumbered code shrinks over time, and there's less of a chance of a webrev spanning encumbered and non-encumbered code. I'd assume that you'll continue to use the internal review systems just for those code reviews. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071011/7a58a2ca/attachment.html From robilad at kaffe.org Thu Oct 11 16:41:02 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 12 Oct 2007 01:41:02 +0200 Subject: Publishing code reviews In-Reply-To: <470EAEF5.2060002@Sun.COM> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> Message-ID: <470EB48E.7040006@kaffe.org> Dmitri Trembovetski wrote: >> The robot only sends e-mail messages to specific reviewers, not to >> mailing lists. That's fine internally, but we should likely also have >> the robot cc: e-mails to the appropriate public lists so that anyone can >> read the review traffic. These need not be the foo-dev lists; we could >> set up a parallel set of, say, foo-review lists. > > I guess it wouldn't hurt, but we don't do anything like > that internally because most people don't care much > about other's code reviews - there's enough traffic > already. If they do, they're the reviewers =) Having review traffic on mailing lists, where it can be indexed by search engines, proved invaluable to me time after time when I was dealing with some obscure 'not_quite_a_bug' in some piece of software, as it let me read my way into figuring out 'what the hell were they thinking' without having to tri-jump around mailing list archives, bugzilla, and CVS/SVN data. So I'd suggest, for the sake of the future generations trying to find lost needles in the growing OpenJDK haystack, to flood the review lists. cheers, dalibor topic From tobrien at discursive.com Thu Oct 11 16:53:32 2007 From: tobrien at discursive.com (Tim O'Brien) Date: Thu, 11 Oct 2007 18:53:32 -0500 Subject: Publishing code reviews In-Reply-To: <470EB48E.7040006@kaffe.org> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> Message-ID: <7260cf030710111653h716e157bw5545e4a284abef72@mail.gmail.com> On 10/11/07, Dalibor Topic wrote: > > Dmitri Trembovetski wrote: > >> The robot only sends e-mail messages to specific reviewers, not to > >> mailing lists. That's fine internally, but we should likely also have > >> the robot cc: e-mails to the appropriate public lists so that anyone > can > >> read the review traffic. These need not be the foo-dev lists; we could > >> set up a parallel set of, say, foo-review lists. > > > > I guess it wouldn't hurt, but we don't do anything like > > that internally because most people don't care much > > about other's code reviews - there's enough traffic > > already. If they do, they're the reviewers =) > > Having review traffic on mailing lists, where it can be indexed by > search engines, proved invaluable to me time after time when I was > dealing with some obscure 'not_quite_a_bug' in some piece of software, > as it let me read my way into figuring out 'what the hell were they > thinking' without having to tri-jump around mailing list archives, > bugzilla, and CVS/SVN data. > > So I'd suggest, for the sake of the future generations trying to find > lost needles in the growing OpenJDK haystack, to flood the review lists. > > cheers, > dalibor topic > FWIW, I've started submitting most of the OpenJDK lists to Nabble for indexing. I'm not sure how long it takes them to add it to the index. -- ------ Tim O'Brien: (847) 863-7045 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071011/d46801c7/attachment.html From Dmitri.Trembovetski at Sun.COM Thu Oct 11 17:01:24 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 17:01:24 -0700 Subject: Publishing code reviews In-Reply-To: <470EB48E.7040006@kaffe.org> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> Message-ID: <470EB954.7050403@Sun.COM> Dalibor Topic wrote: > Having review traffic on mailing lists, where it can be indexed by > search engines, proved invaluable to me time after time when I was > dealing with some obscure 'not_quite_a_bug' in some piece of software, > as it let me read my way into figuring out 'what the hell were they > thinking' without having to tri-jump around mailing list archives, > bugzilla, and CVS/SVN data. > > So I'd suggest, for the sake of the future generations trying to find > lost needles in the growing OpenJDK haystack, to flood the review lists. OK, good point. Thanks, Dmitri From Peter.Kessler at Sun.COM Thu Oct 11 17:44:03 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 11 Oct 2007 17:44:03 -0700 Subject: Publishing code reviews In-Reply-To: <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> Message-ID: <470EC353.50609@Sun.COM> Tim O'Brien wrote: > > > On 10/11/07, *Peter B. Kessler* > wrote: > > Tim O'Brien wrote: > > > > > > > On 10/11/07, *Mark Reinhold* > >> wrote: > > > > > Would we need to somehow filter out the webrevs which > > > contain closed sources? > > > > Yes. That's a Sun-internal problem, though, so let's discuss it > > internally. > > > > > > > > That's interesting, what sort of code is closed? Is there ever > going > > to be a case where a webrev contains certain sections that are public > > and certain sections that are private? since you mentioned it on a > > public list, could you give us a sense of what the public is > missing? > > Think of the code we can't release because of the encumberances. > If we have to make changes in that code, we need to get reviews, > but we can't ask the community for help with those reviews. > > Clearly the less code we have that we can't put in the open the > better. But as long as that set is non-empty, it's something we > have to deal with, internally. > > > Ok, so just to clear it up for the non-Sun folks this would be things > like the font rasterization stuff that is still encumbered. Ideally > the encumbered code shrinks over time, and there's less of a chance of a > webrev spanning encumbered and non-encumbered code. I'd assume that > you'll continue to use the internal review systems just for those code > reviews. Right. The trick is having a process in place that keeps the webrevs for the internal stuff separate from the open webrevs. I think we'd all much rather everything was open, but it isn't. It's all still exciting and new to be discussing our process stuff out in the open, and this probably won't be the only time we'll confuse you with the hoops we have to jump through. ... peter From kboudnik at gmail.com Thu Oct 11 19:33:12 2007 From: kboudnik at gmail.com (Konstantin Boudnik) Date: Thu, 11 Oct 2007 19:33:12 -0700 Subject: Publishing code reviews In-Reply-To: <470EB48E.7040006@kaffe.org> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> Message-ID: Hello there. Could exchanging of results of 'hg bundle' help in any way? Cos On 10/11/07, Dalibor Topic wrote: > Dmitri Trembovetski wrote: > >> The robot only sends e-mail messages to specific reviewers, not to > >> mailing lists. That's fine internally, but we should likely also have > >> the robot cc: e-mails to the appropriate public lists so that anyone can > >> read the review traffic. These need not be the foo-dev lists; we could > >> set up a parallel set of, say, foo-review lists. > > > > I guess it wouldn't hurt, but we don't do anything like > > that internally because most people don't care much > > about other's code reviews - there's enough traffic > > already. If they do, they're the reviewers =) > > Having review traffic on mailing lists, where it can be indexed by > search engines, proved invaluable to me time after time when I was > dealing with some obscure 'not_quite_a_bug' in some piece of software, > as it let me read my way into figuring out 'what the hell were they > thinking' without having to tri-jump around mailing list archives, > bugzilla, and CVS/SVN data. > > So I'd suggest, for the sake of the future generations trying to find > lost needles in the growing OpenJDK haystack, to flood the review lists. > > cheers, > dalibor topic > From mr at sun.com Thu Oct 11 20:25:42 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 11 Oct 2007 20:25:42 -0700 Subject: Publishing code reviews In-Reply-To: mr@sun.com; Thu, 11 Oct 2007 10:41:05 PDT; <20071011174105.6B0C2625A@eggemoggin.niobe.net> Message-ID: <20071012032542.1F740D0EF@callebaut.niobe.net> > From: Mark Reinhold > Date: Thu, 11 Oct 2007 10:41:05 -0700 > ... > > Comments? Alternatives? A commenter on my blog reminded me about Review Board, a web-based code-review tool out of VMWare [1,2]. At a glance it looks pretty slick, and it supports Mercurial, and it's open-source. Is this something that we should try out? - Mark [1] http://review-board.org [2] http://code.google.com/p/reviewboard/ From Dmitri.Trembovetski at Sun.COM Thu Oct 11 20:52:55 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 11 Oct 2007 20:52:55 -0700 Subject: Publishing code reviews In-Reply-To: <20071012032542.1F740D0EF@callebaut.niobe.net> References: <20071012032542.1F740D0EF@callebaut.niobe.net> Message-ID: <470EEF97.70501@Sun.COM> Mark Reinhold wrote: > A commenter on my blog reminded me about Review Board, a web-based > code-review tool out of VMWare [1,2]. At a glance it looks pretty > slick, and it supports Mercurial, and it's open-source. > > Is this something that we should try out? Yes, we looked at it a while back, it's pretty nice, would definitely be great to use it. I just completely forgot about it. Other folks in our teams looked at it and commented that it would be a great replacement for the Robot. It has some cool stuff like incremental revisions, some IDE integration, inline commenting. And it's written in python.. I believe Igor K. even set up an internal server to try it out, connected to jdk-jrl-sources.dev.java.net. Thanks, Dmitri > > - Mark > > > [1] http://review-board.org > [2] http://code.google.com/p/reviewboard/ From roman at kennke.org Thu Oct 11 22:54:31 2007 From: roman at kennke.org (Roman Kennke) Date: Fri, 12 Oct 2007 07:54:31 +0200 Subject: Publishing code reviews In-Reply-To: <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> Message-ID: <1192168471.13489.15.camel@mercury> Hi, > Ok, so just to clear it up for the non-Sun folks this would be things > like the font rasterization stuff that is still encumbered. I don't think the font rasterizer is still encumbered. What's still missing is the antialiasing rasterizer (to be fixed real soon now), the javax.sound API, some pieces in java.awt.image.* and java.awt.color.*, some JMX/SNMP stuff. Also, see here: http://weblogs.java.net/blog/robogeek/archive/2007/10/openjdk_encumbr.html /Roman -- http://kennke.org/blog/ From roman at kennke.org Thu Oct 11 22:55:41 2007 From: roman at kennke.org (Roman Kennke) Date: Fri, 12 Oct 2007 07:55:41 +0200 Subject: Publishing code reviews In-Reply-To: <470EB48E.7040006@kaffe.org> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> Message-ID: <1192168541.13489.18.camel@mercury> Hi, > >> The robot only sends e-mail messages to specific reviewers, not to > >> mailing lists. That's fine internally, but we should likely also have > >> the robot cc: e-mails to the appropriate public lists so that anyone can > >> read the review traffic. These need not be the foo-dev lists; we could > >> set up a parallel set of, say, foo-review lists. > > > > I guess it wouldn't hurt, but we don't do anything like > > that internally because most people don't care much > > about other's code reviews - there's enough traffic > > already. If they do, they're the reviewers =) > > Having review traffic on mailing lists, where it can be indexed by > search engines, proved invaluable to me time after time when I was > dealing with some obscure 'not_quite_a_bug' in some piece of software, > as it let me read my way into figuring out 'what the hell were they > thinking' without having to tri-jump around mailing list archives, > bugzilla, and CVS/SVN data. > > So I'd suggest, for the sake of the future generations trying to find > lost needles in the growing OpenJDK haystack, to flood the review lists. I second that. /Roman -- http://kennke.org/blog/ From aph at redhat.com Fri Oct 12 03:10:35 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Oct 2007 11:10:35 +0100 Subject: Publishing code reviews In-Reply-To: <20071011174105.6B0C2625A@eggemoggin.niobe.net> References: <20071011174105.6B0C2625A@eggemoggin.niobe.net> Message-ID: <18191.18459.936227.972172@zebedee.pink> Mark Reinhold writes: > One of the engineering practices that's served the JDK development team > well for many years now is that of peer-based code reviews. In mainline > JDK development at least one review is required for every code change, > and two or more are needed as release milestones approach. > > Reviews are most often performed with the help of a tool called "webrev", > which basically diffs two source trees and generates a pile of HTML that > you can view in a browser (sample: [1]). webrev was originally written > by the Solaris team; lately it's been revised and extended [2] to support > Mercurial and Subversion in addition to the old internal TeamWare SCM. > > A lot of the e-mail that JDK developers read and write is, naturally, > about code reviews. It's not exactly convenient to attach webrevs to > e-mail messages, so people typically either copy them to a directory > published by a private web server and send the URL around, or they copy > them over to an NFS-exported filesystem and send a long pathname (and > cross their fingers if a potential reviewer is far away network-wise). > > The bug here, of course, is that these publication methods don't make > code reviews visible on the open web, and this is one reason that most > JDK developers have thus far been reluctant to move more of their e-mail > traffic onto the public openjdk.java.net mailing lists. > > So: How should we solve this problem in a way that works for all JDK > contributors, whether or not they work for Sun? > > We could build something slick and fancy, like Google's Mondrian [3], > but I think it's relatively more important to get something up quickly > and work on improving it later. > > A more expedient solution would be to construct something like the > OpenSolaris code-review site [4,5], where contributors can use rsync, > scp, and sftp (all via SSH) to upload webrevs to temporary storage on > a public server. SSH keys will ultimately be required in order to push > changesets into the public Mercurial repositories, so contributors will > need to create and register SSH keys anyway, and the code-review site > can easily leverage the same underlying infrastructure. > > Comments? Alternatives? Here's a really simple suggestion: convert the diffs to "diff -u" format and email them to a list. The list gets archived, so all the diffs are available forever. There doesn't have to be one single format for a diff: some people may continue to use webrev, but others may look at simple diffs. Also, search tools such as Google work well on archived mailing lists. It's important to reduce the barriers to entry for people wanting to work on OpenJDK, and while full-time contributors may well be highly motivated to learn new tools, more casual browsers will be deterred by having to do so. >From looking at the sample in [1], while it is attractively presented, it's not clear to me that the nice formatting is sufficient to justify the disadvantage to a user of not being able to use the mail reader of their choice. Another issue is long-term archiving: I have quite often gone back five or ten years to look at a particular gcc patch to see what problem it was supposed to solve and read the patch reviews. This doesn't depend on any one server because gcc discussions are archived on many servers run by different organizations. Being able to reach back in time is a vital part of the open development process, and you don't want to depend on any one organization's server infrastructure. Finally, a server that only keeps webrevs for a limited period of time is a bad idea. We need to be able to find every version of every patch that has ever been proposed. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From tobrien at discursive.com Fri Oct 12 07:29:04 2007 From: tobrien at discursive.com (Tim O'Brien) Date: Fri, 12 Oct 2007 09:29:04 -0500 Subject: Nabble requests submitted Message-ID: <7260cf030710120729y5506bc32r29c4291bcbe96d88@mail.gmail.com> If you want a dashboard for list activity: http://www.nabble.com/OpenJDK-f27642.html I've submitted requests for all the list, they should show up over the next few days. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071012/1bd7156e/attachment.html From David.Herron at Sun.COM Fri Oct 12 07:40:39 2007 From: David.Herron at Sun.COM (David Herron) Date: Fri, 12 Oct 2007 07:40:39 -0700 Subject: Publishing code reviews In-Reply-To: <1192168471.13489.15.camel@mercury> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> <1192168471.13489.15.camel@mercury> Message-ID: <470F8767.10206@sun.com> Roman Kennke wrote: > Hi, > >> Ok, so just to clear it up for the non-Sun folks this would be things >> like the font rasterization stuff that is still encumbered. >> > > I don't think the font rasterizer is still encumbered. What's still > missing is the antialiasing rasterizer (to be fixed real soon now), the > javax.sound API, some pieces in java.awt.image.* and java.awt.color.*, > some JMX/SNMP stuff. Also, see here: > > http://weblogs.java.net/blog/robogeek/archive/2007/10/openjdk_encumbr.html > > /Roman > > Roman, thank you for pointing to my blog entry. I found one thing a little curious while creating that blog posting - I wasn't able to find a public list of all the encumbrances. I know that internally we have a list, and probably someone is actively tracking the status of the list. On the openjdk.java.net site some of the groups have listed their encumbrances. But it's not clear whether those separate lists manage to list all the encumbrances. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071012/c188efa3/attachment.html From roman at kennke.org Fri Oct 12 07:50:51 2007 From: roman at kennke.org (Roman Kennke) Date: Fri, 12 Oct 2007 16:50:51 +0200 Subject: Publishing code reviews In-Reply-To: <470F8767.10206@sun.com> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> <1192168471.13489.15.camel@mercury> <470F8767.10206@sun.com> Message-ID: <1192200651.6144.8.camel@mercury> Hi David, > > > Ok, so just to clear it up for the non-Sun folks this would be things > > > like the font rasterization stuff that is still encumbered. > > > > > > > I don't think the font rasterizer is still encumbered. What's still > > missing is the antialiasing rasterizer (to be fixed real soon now), the > > javax.sound API, some pieces in java.awt.image.* and java.awt.color.*, > > some JMX/SNMP stuff. Also, see here: > > > > http://weblogs.java.net/blog/robogeek/archive/2007/10/openjdk_encumbr.html > > > > /Roman > > > > > > Roman, thank you for pointing to my blog entry. I found one thing a > little curious while creating that blog posting - I wasn't able to > find a public list of all the encumbrances. I know that internally we > have a list, and probably someone is actively tracking the status of > the list. On the openjdk.java.net site some of the groups have listed > their encumbrances. But it's not clear whether those separate lists > manage to list all the encumbrances. It's even worse, for example, the font rasterizer group page still lists the font rasterizer as beeing encumbered, while in reality it isn't. What I do is look into the binary blob and see which packages are still included in the rt-closed.jar :-) That's a pretty comprehensive list of encumbered areas. Cheers, Roman -- http://kennke.org/blog/ From Dmitri.Trembovetski at Sun.COM Fri Oct 12 22:48:54 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 12 Oct 2007 22:48:54 -0700 Subject: JDK 7 build 22 is available at the openjdk.java.net website In-Reply-To: <470FF86D.6090603@Sun.COM> References: <470FF86D.6090603@Sun.COM> Message-ID: <47105C46.2060107@Sun.COM> Xiomara.Jayasena at Sun.COM wrote: > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b22.html This page is missing. Thanks, Dmitri > > Thanks, > -Xiomara > From Xiomara.Jayasena at Sun.COM Sat Oct 13 00:08:02 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Sat, 13 Oct 2007 00:08:02 -0700 Subject: JDK 7 build 22 is available at the openjdk.java.net website In-Reply-To: <47105C46.2060107@Sun.COM> References: <470FF86D.6090603@Sun.COM> <47105C46.2060107@Sun.COM> Message-ID: <47106ED2.5090705@sun.com> Dmitri Trembovetski wrote: > > > Xiomara.Jayasena at Sun.COM wrote: >> Summary of changes: >> http://download.java.net/jdk7/changes/jdk7-b22.html > > This page is missing. I have no problem seeing it and I am not on Sun's network. -Xiomara > > Thanks, > Dmitri > > >> >> Thanks, >> -Xiomara >> From jeroen at sumatra.nl Sat Oct 13 01:49:09 2007 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 13 Oct 2007 10:49:09 +0200 Subject: JDK 7 build 22 is available at the openjdk.java.net website In-Reply-To: <47106ED2.5090705@sun.com> References: <470FF86D.6090603@Sun.COM> <47105C46.2060107@Sun.COM> <47106ED2.5090705@sun.com> Message-ID: Xiomara Jayasena wrote: > Dmitri Trembovetski wrote: > > > > > > Xiomara.Jayasena at Sun.COM wrote: > >> Summary of changes: > >> http://download.java.net/jdk7/changes/jdk7-b22.html > > > > This page is missing. > I have no problem seeing it and I am not on Sun's network. We go through this every new build. Apparantly running web servers is not Sun's strong suit. Try refreshing a bunch of times, that usually makes it work after a while. Regards, Jeroen From Kelly.Ohair at Sun.COM Sat Oct 13 12:11:33 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 13 Oct 2007 12:11:33 -0700 Subject: JDK 7 build 22 is available at the openjdk.java.net website In-Reply-To: References: <470FF86D.6090603@Sun.COM> <47105C46.2060107@Sun.COM> <47106ED2.5090705@sun.com> Message-ID: <47111865.7040001@sun.com> These builds are cutting edge, and you should never expect any of them to be perfect, you should expect a few problems. Especially right now, as we transition to Mercurial and actively work on opening up more and more, there has never been more restructuring and major changes to the source base that ever before. So don't be surprised if we have introduced some regressions in the last few builds, we aren't doing it intentionally, but we are trying to move as quickly as possible to make live Mercurial repositories available. Build 23 and 24 may not be very interesting, no new fancy features or critical bug fixes, but after Build 24 it will be a whole new Mercurial world. So hold onto your hats for a few more weeks, it will be an adventure. -kto From mr at sun.com Thu Oct 18 11:26:25 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 18 Oct 2007 11:26:25 -0700 Subject: Publishing code reviews In-Reply-To: aph@redhat.com; Fri, 12 Oct 2007 11:10:35 BST; <18191.18459.936227.972172@zebedee.pink> Message-ID: <20071018182625.3CB4162F8@eggemoggin.niobe.net> > Date: Fri, 12 Oct 2007 11:10:35 +0100 > From: Andrew Haley > Here's a really simple suggestion: convert the diffs to "diff -u" > format and email them to a list. ... Your suggestions of sending diff -u output to mailing lists, for those who prefer that format, and of making sure that those lists are archived (in many places) are well taken. It seems that there's a hierarchy of code-review formats in which each format encompasses those below it. The lowest level is simple uniform diffs (diff -u), which are universal. Next come webrevs, which include uniform diffs, and then fancier, semi-automated systems such as the "robot" (which already generates webrevs) and Review Board (which could likely be hacked into doing so). As long as we build infrastructure that can support every layer of the hierarchy, everyone should be happy. > ... > > Finally, a server that only keeps webrevs for a limited period of time > is a bad idea. We need to be able to find every version of every > patch that has ever been proposed. In most cases it should be possible to reconstruct a webrev from the corresponding diff in the e-mail archive. The only exceptions I can think of will be diffs that aren't relative to a specific published Mercurial changeset. Still, disk is cheap, and ZFS compresses HTML quite nicely, so perhaps we should aim to keep webrevs around forever. Thanks for your comments. It's always good to get more outside perspectives on this sort of thing. - Mark From aph at redhat.com Fri Oct 19 03:19:07 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Oct 2007 11:19:07 +0100 Subject: Publishing code reviews In-Reply-To: <20071018182625.3CB4162F8@eggemoggin.niobe.net> References: <18191.18459.936227.972172@zebedee.pink> <20071018182625.3CB4162F8@eggemoggin.niobe.net> Message-ID: <18200.33947.674018.317890@zebedee.pink> Mark Reinhold writes: > > Date: Fri, 12 Oct 2007 11:10:35 +0100 > > From: Andrew Haley > > > Here's a really simple suggestion: convert the diffs to "diff -u" > > format and email them to a list. ... > > Your suggestions of sending diff -u output to mailing lists, for those > who prefer that format, and of making sure that those lists are archived > (in many places) are well taken. > > It seems that there's a hierarchy of code-review formats in which each > format encompasses those below it. The lowest level is simple uniform > diffs (diff -u), which are universal. Next come webrevs, which include > uniform diffs, and then fancier, semi-automated systems such as the > "robot" (which already generates webrevs) and Review Board (which could > likely be hacked into doing so). > > As long as we build infrastructure that can support every layer of the > hierarchy, everyone should be happy. Yes, but be sure that reviewer comments are also mailed as a reply to the diff -u output to the mailing lists. Where are the reviewer comments for http://cr.opensolaris.org/~dp/i2o-del/ ? I can't find them anywhere. > > > ... > > > > Finally, a server that only keeps webrevs for a limited period of time > > is a bad idea. We need to be able to find every version of every > > patch that has ever been proposed. > > In most cases it should be possible to reconstruct a webrev from the > corresponding diff in the e-mail archive. Right. Incidentally, the only place that "diff -u" really goes wrong is when files are moved. We still don't have a nice way to publish such changes on the gcc list, but then we very rarely move fies. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mark at klomp.org Sat Oct 20 14:16:00 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 20 Oct 2007 23:16:00 +0200 Subject: Publishing code reviews In-Reply-To: <1192168541.13489.18.camel@mercury> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> <1192168541.13489.18.camel@mercury> Message-ID: <1192914960.9521.23.camel@localhost.localdomain> Hi, On Fri, 2007-10-12 at 07:55 +0200, Roman Kennke wrote: > > Having review traffic on mailing lists, where it can be indexed by > > search engines, proved invaluable to me time after time when I was > > dealing with some obscure 'not_quite_a_bug' in some piece of software, > > as it let me read my way into figuring out 'what the hell were they > > thinking' without having to tri-jump around mailing list archives, > > bugzilla, and CVS/SVN data. > > > > So I'd suggest, for the sake of the future generations trying to find > > lost needles in the growing OpenJDK haystack, to flood the review lists. > > I second that. I believe I am not even the third anymore, but I would strongly support the same. Having email as the common backend is really, really convenient. mailinglists are archived everywhere, you can easily turn them into nntp or rrs feeds (like gmane does) and writing little bots to monitor the lists and take appropriate actions is super easy (if you aren't dirty of a little perl now and then). As an example here are the mailinglists in use for GNU Classpath, but I believe most larger free software projects have something similar: classpath at gnu.org general discussion, announcements, developer talk, ideas, etc. but not formal patch proposals. Formal patch proposals go to... classpath-patches at gnu.org posting of proposed patches (in diff -u format) for review. All replies and suggestions for improvements and final approval of the patches also go to this list. Some projects (like gcc) also have a bot that you can inform of the formal patch proposal so it can monitor whether there was any reply. In classpath we require developers to ping their patches themselves if there is no reply in a reasonable time. classpath-commits at gnu.org - a robot posts all commit messages plus the CVSWeb URLs of anything that actually hits the archives. Another robot picks up any commit messages from this list to update the bugzilla bug entries mentioned in the commit message (and humans double check every commit to make sure that the accompanying patch was discussed on the patches list). classpath-bugs at gnu.org All new or modified bugzilla entries get posted here (which includes the commit-bot updates when a commit message contains a bug number). Replying to these emails also updates the bugzilla entries, so it is an easy way to interact with the bug reporters and to monitor when a particular issue is often reported or commented on. classpath-testresults at gnu.org posting of autobuilder results of compiling classpath in various configurations, with different compilers, runtimes and against different (replies go to the general list). There should be a robot behind this one also, but currently it is the sharp eyes of the various developers pinging every involved developer and the general list when a commit hit the autobuilders that triggers a regression (or worse!) a build failure. - This list is super handy when there was a continuous stream of build/test results on various conficurations, it enables sonmeone to easily hunt down when a particular issue arose on a particular architecture over time. So there are different backends to some of these lists (cvs, bugzilla, custom build bots), but humans value the actual email messages the most. Also humans can kind of adjust their involvement, someone just sending an occasional patch will most likely only monitor the general and patches list (a requirement for committers), but maintainers, bugmasters and integrators will most likely subscribe to all lists. And everybody can use the various email archive search tools to easily locate past information. Cheers, Mark From mark at klomp.org Sat Oct 20 14:31:10 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 20 Oct 2007 23:31:10 +0200 Subject: Publishing code reviews In-Reply-To: <1192200651.6144.8.camel@mercury> References: <470E7363.70508@Sun.COM> <20071011225425.6A687625A@eggemoggin.niobe.net> <7260cf030710111602k1e722cecv221da40fa7637113@mail.gmail.com> <470EB118.1080805@Sun.COM> <7260cf030710111638v6bbd3d6dh88f898d6af345368@mail.gmail.com> <1192168471.13489.15.camel@mercury> <470F8767.10206@sun.com> <1192200651.6144.8.camel@mercury> Message-ID: <1192915870.9521.30.camel@localhost.localdomain> Hi, On Fri, 2007-10-12 at 16:50 +0200, Roman Kennke wrote: > > Roman, thank you for pointing to my blog entry. I found one thing a > > little curious while creating that blog posting - I wasn't able to > > find a public list of all the encumbrances. I know that internally we > > have a list, and probably someone is actively tracking the status of > > the list. On the openjdk.java.net site some of the groups have listed > > their encumbrances. But it's not clear whether those separate lists > > manage to list all the encumbrances. It would be nice to have to list public, and know whether someone inside Sun is already working on something, where progress is posted and what parts need more community help. > What I do is look into the binary blob and see which packages are still > included in the rt-closed.jar :-) That's a pretty comprehensive list of > encumbered areas. This is also why icedtea is so nice. You can easily find the encumbered parts by looking in the rt/ directory, which provides alternative free implementation classes, and the patches/ directory which contains patches of those classes that call proprietary backends so they call the free alternatives. There is a partial status list in the icedtea.classpath.org FAQ entry. Cheers, Mark From mark at klomp.org Sat Oct 20 15:25:03 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 21 Oct 2007 00:25:03 +0200 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <470BDD1A.4060908@Sun.COM> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> Message-ID: <1192919103.9521.68.camel@localhost.localdomain> Hi Xiomara, On Tue, 2007-10-09 at 12:57 -0700, Xiomara.Jayasena at Sun.COM wrote: > Stephen J. McConnell wrote: > > On Tue, 2007-10-09 at 14:17 +0200, Dalibor Topic wrote: > > > > > Xiomara.Jayasena at Sun.COM wrote: > > > > > > > > As many of you know the jdk 7 workspaces will be moving from > > > > Teamware to > > > > Mercurial. As of now we host svn repositories here: > > > > https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ > > > > and > > > > here: > > > > https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ > > > > > > > > Once JDK 7 moves to Mercurial we would like to know whether > > > > there is a > > > > need to keep the svn repositories out there and if so forever? > > > > overlap > > > > for sometime? I am trying to figure out what would be best for > > > > most > > > > people. > > > > > > > I don't think there is a need to keep them around, as you have the > > > zip-ed/tar-ed source code downloads for people just wanting to > > > fetch and > > > build the 'latest' build, while a source code repository, for me > > > at > > > least, is the place where the actual work is happening. > > > > > > And there can be only one of those. ;) > > > > I agree completely. > > > > Backups of legacy to take care of the past and move on to Mercurial > > for > > the future. > > Thank you for your feeback -- these responses along with others I have > received seem to be in the same line of thought. So it is OK to do > away with the svn repositories once the Mercurial ones are up. Yes I think so. If the old history is imported into mercurial I don't see any reason to keep the svn repos around. There is also a mercurial mirror of the svn repositories, with all changesets already at http://icedtea.classpath.org/hg/openjdk/ This can be kept around for people who want to view the history also. I personally found that mercurial mirror handy to easy figure out when what changed between source drops (since with mercurial as opposed to subversion you don't need any network connection which greatly slows things down for doing quick changeset searches). Cheers, Mark From Kelly.Ohair at Sun.COM Sun Oct 21 13:32:16 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 21 Oct 2007 13:32:16 -0700 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <1192919103.9521.68.camel@localhost.localdomain> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> Message-ID: <471BB750.4090306@sun.com> The official Mercurial repositories will have NO history from the TeamWare workspaces or SubVersion repositories, they will be fresh repositories starting with the promotion of Build 23. Importing history from one SCM to another is an inexact science and we want accurate Mercurial repository history. With Mercurial, the working set files can easily be displaced with a different source tree if you wanted to see the differences between past promotions and the current state of a repository. -kto Mark Wielaard wrote: > Hi Xiomara, > > On Tue, 2007-10-09 at 12:57 -0700, Xiomara.Jayasena at Sun.COM wrote: >> Stephen J. McConnell wrote: >>> On Tue, 2007-10-09 at 14:17 +0200, Dalibor Topic wrote: >>> >>>> Xiomara.Jayasena at Sun.COM wrote: >>>>> As many of you know the jdk 7 workspaces will be moving from >>>>> Teamware to >>>>> Mercurial. As of now we host svn repositories here: >>>>> https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ >>>>> and >>>>> here: >>>>> https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk7/trunk/ >>>>> >>>>> Once JDK 7 moves to Mercurial we would like to know whether >>>>> there is a >>>>> need to keep the svn repositories out there and if so forever? >>>>> overlap >>>>> for sometime? I am trying to figure out what would be best for >>>>> most >>>>> people. >>>>> >>>> I don't think there is a need to keep them around, as you have the >>>> zip-ed/tar-ed source code downloads for people just wanting to >>>> fetch and >>>> build the 'latest' build, while a source code repository, for me >>>> at >>>> least, is the place where the actual work is happening. >>>> >>>> And there can be only one of those. ;) >>> I agree completely. >>> >>> Backups of legacy to take care of the past and move on to Mercurial >>> for >>> the future. >> Thank you for your feeback -- these responses along with others I have >> received seem to be in the same line of thought. So it is OK to do >> away with the svn repositories once the Mercurial ones are up. > > Yes I think so. If the old history is imported into mercurial I don't > see any reason to keep the svn repos around. There is also a mercurial > mirror of the svn repositories, with all changesets already at > http://icedtea.classpath.org/hg/openjdk/ This can be kept around for > people who want to view the history also. I personally found that > mercurial mirror handy to easy figure out when what changed between > source drops (since with mercurial as opposed to subversion you don't > need any network connection which greatly slows things down for doing > quick changeset searches). > > Cheers, > > Mark > From Phil.Race at Sun.COM Wed Oct 24 09:25:41 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 24 Oct 2007 09:25:41 -0700 Subject: Publishing code reviews In-Reply-To: <1192914960.9521.23.camel@localhost.localdomain> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> <1192168541.13489.18.camel@mercury> <1192914960.9521.23.camel@localhost.localdomain> Message-ID: <471F7205.1030008@sun.com> Mark, Mark Wielaard wrote: > I believe I am not even the third anymore, but I would strongly support > the same. Having email as the common backend is really, really > convenient. mailinglists are archived everywhere, you can easily turn > them into nntp or rrs feeds (like gmane does) and writing little bots to > monitor the lists and take appropriate actions is super easy (if you > aren't dirty of a little perl now and then). > > As an example here are the mailinglists in use for GNU Classpath, but I > believe most larger free software projects have something similar: > > classpath at gnu.org general discussion, announcements, developer talk, > ideas, etc. but not formal patch proposals. Formal patch proposals go > to... > > classpath-patches at gnu.org posting of proposed patches (in diff -u > format) for review. All replies and suggestions for improvements and > final approval of the patches also go to this list. Some projects (like > gcc) also have a bot that you can inform of the formal patch proposal so > it can monitor whether there was any reply. In classpath we require > developers to ping their patches themselves if there is no reply in a > reasonable time. Emailing diffs out to a list is fine, so long as this isn't the actual review format for the identified reviewers who will want a webrev. By "identified reviewers", perhaps thing that wasn't clear about our processes is that the change author identifies the reviewers who are most appropriate and they are on the hook to respond. We don't send patches to a list and hope for a response. In fact no one I know of here would want to receive emails of all the patches, so likely wouldn't subscribe to such a list. What does "ping their patches" mean? > classpath-bugs at gnu.org All new or modified bugzilla entries get posted > here (which includes the commit-bot updates when a commit message > contains a bug number). Replying to these emails also updates the > bugzilla entries, so it is an easy way to interact with the bug > reporters and to monitor when a particular issue is often reported or > commented on. I'd really like to see updates to bugs emailed out .. hopefully soon, -phil. From robilad at kaffe.org Wed Oct 24 14:35:25 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 24 Oct 2007 23:35:25 +0200 Subject: Publishing code reviews In-Reply-To: <471F7205.1030008@sun.com> References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> <1192168541.13489.18.camel@mercury> <1192914960.9521.23.camel@localhost.localdomain> <471F7205.1030008@sun.com> Message-ID: <471FBA9D.6060001@kaffe.org> Phil Race wrote: > What does "ping their patches" mean? To politely remind the list to review their patches. > I'd really like to see updates to bugs emailed out .. hopefully soon, Great, thanks! cheers, dalibor topic From robilad at kaffe.org Wed Oct 24 14:39:07 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 24 Oct 2007 23:39:07 +0200 Subject: Publishing code reviews In-Reply-To: References: <20071011225425.6A687625A@eggemoggin.niobe.net> <470EAEF5.2060002@Sun.COM> <470EB48E.7040006@kaffe.org> Message-ID: <471FBB7B.20009@kaffe.org> Konstantin Boudnik wrote: > Hello there. > > Could exchanging of results of 'hg bundle' help in any way? Hi Cos, I think that would track only that patches in the repo, not the communication around them, but I'm not a hg expert ... yet. ;) cheers, dalibor topic From robilad at kaffe.org Wed Oct 24 14:40:36 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 24 Oct 2007 23:40:36 +0200 Subject: Publishing code reviews In-Reply-To: <20071012032542.1F740D0EF@callebaut.niobe.net> References: <20071012032542.1F740D0EF@callebaut.niobe.net> Message-ID: <471FBBD4.5060404@kaffe.org> Mark Reinhold wrote: >> From: Mark Reinhold >> Date: Thu, 11 Oct 2007 10:41:05 -0700 > >> ... >> >> Comments? Alternatives? > > A commenter on my blog reminded me about Review Board, a web-based > code-review tool out of VMWare [1,2]. At a glance it looks pretty > slick, and it supports Mercurial, and it's open-source. > > Is this something that we should try out? > Looks nice on the face of it. Not packaged anywhere yet, afaict, but that's nothing that can't be fixed. ;) cheers, dalibor topic From robilad at kaffe.org Wed Oct 24 14:52:16 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 24 Oct 2007 23:52:16 +0200 Subject: Nabble requests submitted In-Reply-To: <7260cf030710120729y5506bc32r29c4291bcbe96d88@mail.gmail.com> References: <7260cf030710120729y5506bc32r29c4291bcbe96d88@mail.gmail.com> Message-ID: <471FBE90.6000608@kaffe.org> Tim O'Brien wrote: > If you want a dashboard for list activity: > > http://www.nabble.com/OpenJDK-f27642.html > > I've submitted requests for all the list, they should show up over the next > few days. > Nice, thank you very much - I like that it shows all the list traffic in one place for a quick overview. cheers, dalibor topic From robilad at kaffe.org Wed Oct 24 14:58:45 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 24 Oct 2007 23:58:45 +0200 Subject: Project proposal: Multi-Language VM In-Reply-To: