From mr at sun.com Mon Oct 1 04:29:13 2007 From: mr at sun.com (Mark Reinhold) Date: Sun, 30 Sep 2007 21:29:13 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: iris.clark@sun.com; Fri, 28 Sep 2007 10:57:29 PDT; <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> Message-ID: <20071001042913.13080C086@callebaut.niobe.net> > Date: Fri, 28 Sep 2007 10:57:29 -0700 (PDT) > From: iris.clark at sun.com > I'd like to propose creation of the OpenJDK Conformance Group. ... Thanks Iris. I hereby second this proposal. Per the interim governance guidelines for Groups [1], after two weeks have passed for discussion the Interim Governance Board will decide whether to approve the creation of this Group, and whether this Group shall have the power to grant Membership. - Mark [1] http://openjdk.java.net/groups/ From Jonathan.Gibbons at Sun.COM Mon Oct 1 05:07:36 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 30 Sep 2007 22:07:36 -0700 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <20071001042913.13080C086@callebaut.niobe.net> References: <20071001042913.13080C086@callebaut.niobe.net> Message-ID: I second the proposal as well. -- Jon On Sep 30, 2007, at 9:29 PM, Mark Reinhold wrote: >> Date: Fri, 28 Sep 2007 10:57:29 -0700 (PDT) >> From: iris.clark at sun.com > >> I'd like to propose creation of the OpenJDK Conformance Group. ... > > Thanks Iris. > > I hereby second this proposal. > > Per the interim governance guidelines for Groups [1], after two weeks > have passed for discussion the Interim Governance Board will decide > whether to approve the creation of this Group, and whether this Group > shall have the power to grant Membership. > > - Mark > > > [1] http://openjdk.java.net/groups/ From mark at klomp.org Mon Oct 1 07: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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gnu_andrew at member.fsf.org Mon Oct 1 11: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 14: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: From Xiomara.Jayasena at Sun.COM Mon Oct 1 18: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: From mark at klomp.org Mon Oct 1 19: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 21: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 Tue Oct 2 00: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 12: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 13: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 19:49:17 2007 From: iris.clark at Sun.COM (Iris Clark) 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 19: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 22: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: From mark at klomp.org Sun Oct 7 17: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 19: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: From Onno.Kluyt at Sun.COM Mon Oct 8 14: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 17: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 12: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 16: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 19: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: From robilad at kaffe.org Tue Oct 9 21: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 07: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 17: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 18: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 18: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: From Phil.Race at Sun.COM Thu Oct 11 18: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 18: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 18: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 18: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 18: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 18: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 19: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 19: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 22: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 23: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: From Dmitri.Trembovetski at Sun.COM Thu Oct 11 23: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 23: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 23: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: From robilad at kaffe.org Thu Oct 11 23: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 23: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: From Dmitri.Trembovetski at Sun.COM Fri Oct 12 00: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 Fri Oct 12 00: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 Fri Oct 12 02: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 Fri Oct 12 03: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 Fri Oct 12 03: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 Fri Oct 12 05: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 Fri Oct 12 05: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 10: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 14: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: From David.Herron at Sun.COM Fri Oct 12 14: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: From roman at kennke.org Fri Oct 12 14: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 Sat Oct 13 05: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 07: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 08: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 19: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 18: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 10: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 21: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 21: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 22: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 20: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 16: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 21: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 21: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 21: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 21: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 21: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: References: Message-ID: <471FC015.8090200@kaffe.org> John Rose wrote: > 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]. > Hi John, there hasn't been much discussion of your proposal on discuss at openjdk (I presume because it's the obviously right thing to do (TM) :) so I just wanted to pop in and say that I love the idea, and I'd be very happy to see such a project being developed inside OpenJDK. cheers, dalibor topic From John.Rose at Sun.COM Wed Oct 24 22:07:26 2007 From: John.Rose at Sun.COM (John Rose) Date: Wed, 24 Oct 2007 15:07:26 -0700 Subject: Project proposal: Multi-Language VM In-Reply-To: <471FC015.8090200@kaffe.org> References: <471FC015.8090200@kaffe.org> Message-ID: <942D5370-4E2C-495D-804C-BFDE64497EBC@sun.com> Thank you! We'll probably be sending out a CFV to the HotSpot Group later today. -- John On Oct 24, 2007, at 2:58 PM, Dalibor Topic wrote: > John Rose wrote: >> 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]. >> > > Hi John, > > there hasn't been much discussion of your proposal on > discuss at openjdk (I > presume because it's the obviously right thing to do (TM) :) so I just > wanted to pop in and say that I love the idea, and I'd be very > happy to > see such a project being developed inside OpenJDK. > > cheers, > dalibor topic From ernst.matthias at gmail.com Mon Oct 29 10:44:12 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Mon, 29 Oct 2007 11:44:12 +0100 Subject: jdk-collaboration forum Message-ID: <22ec15240710290344v1d4fcae6ne712218085c4336f@mail.gmail.com> Hi, I've posted three messages over a week ago on the collaboration forum, including one about its relation to the openjdk mailing lists. There was no answer, and it seems to indicate that jdk-collaboration is effectively dead and has been replaced by openjdk. Is that right and should someone announce that on / shut down jdk-collaboration? Cheers Matthias From neppanepenthes at yahoo.it Mon Oct 29 12:51:11 2007 From: neppanepenthes at yahoo.it (Massimo Perga) Date: Mon, 29 Oct 2007 12:51:11 +0000 (GMT) Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform Message-ID: <706832.48951.qm@web27813.mail.ukl.yahoo.com> Hello All, I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in. I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version. To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ? Thanks in advance, Regards, Max ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html From robilad at kaffe.org Mon Oct 29 13:10:43 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Mon, 29 Oct 2007 14:10:43 +0100 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <706832.48951.qm@web27813.mail.ukl.yahoo.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> Message-ID: <4725DBD3.8070001@kaffe.org> Massimo Perga wrote: > Hello All, > I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in. > I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version. > To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ? > The JDK plugin code is not available yet as part of OpenJDK. If you want to work on improving gcjwebplugin's support for OpenJDK/IcedTea, you can do that via the distro-pkg-dev list. cheers, dalibor topic From kurt at intricatesoftware.com Mon Oct 29 14:22:31 2007 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 29 Oct 2007 10:22:31 -0400 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <706832.48951.qm@web27813.mail.ukl.yahoo.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> Message-ID: <200710291022.31911.kurt@intricatesoftware.com> On Monday 29 October 2007 8:51:11 am Massimo Perga wrote: > Hello All, > I'm writing here to know what's the best process to follow in order to > have more informations on such a plug-in. I'm not requesting it... rather, > I'm *offering* to port the current 32-bit Linux version to a native 64-bit > version. To accomplish this task, which is the project that takes care of > such a plug-in ? Otherwise, have I to request a new project ? > > Thanks in advance, > Regards, > Max Myself and Jung-uk Kim have completed making the plugin 64-bit clean for the 1.6 JRL licensed plugin. You can find our work in patchset 2 for BSD: http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html Regards, -Kurt From robilad at kaffe.org Mon Oct 29 16:11:14 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Mon, 29 Oct 2007 17:11:14 +0100 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <200710291022.31911.kurt@intricatesoftware.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> Message-ID: <47260622.1020209@kaffe.org> Kurt Miller wrote: > On Monday 29 October 2007 8:51:11 am Massimo Perga wrote: > >> Hello All, >> I'm writing here to know what's the best process to follow in order to >> have more informations on such a plug-in. I'm not requesting it... rather, >> I'm *offering* to port the current 32-bit Linux version to a native 64-bit >> version. To accomplish this task, which is the project that takes care of >> such a plug-in ? Otherwise, have I to request a new project ? >> >> Thanks in advance, >> Regards, >> Max >> > > Myself and Jung-uk Kim have completed making the plugin 64-bit > clean for the 1.6 JRL licensed plugin. You can find our work in patchset > 2 for BSD: > > http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html > On an unrelated note, would it make sense to create infrastructure for the porting projects inside OpenJDK? I am wondering if we shouldn't create an official 'porters' group, with projects for ports to *BSD, etc. While Sun may not be interested in merging in all such ports into the main OpenJDK tree, it could be useful to have the patch sets maintained centrally as part of the OpenJDK infrastructure. The distributed mercurial setup could give us that liberty, I think. cheers, dalibor topic From volker.simonis at gmail.com Mon Oct 29 16:58:22 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 29 Oct 2007 18:58:22 +0200 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <47260622.1020209@kaffe.org> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> Message-ID: On 10/29/07, Dalibor Topic wrote: > Kurt Miller wrote: > > On Monday 29 October 2007 8:51:11 am Massimo Perga wrote: > > > >> Hello All, > >> I'm writing here to know what's the best process to follow in order to > >> have more informations on such a plug-in. I'm not requesting it... rather, > >> I'm *offering* to port the current 32-bit Linux version to a native 64-bit > >> version. To accomplish this task, which is the project that takes care of > >> such a plug-in ? Otherwise, have I to request a new project ? > >> > >> Thanks in advance, > >> Regards, > >> Max > >> > > > > Myself and Jung-uk Kim have completed making the plugin 64-bit > > clean for the 1.6 JRL licensed plugin. You can find our work in patchset > > 2 for BSD: > > > > http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html > > > On an unrelated note, would it make sense to create infrastructure for > the porting projects inside OpenJDK? I am wondering if we shouldn't > create an official 'porters' group, with projects for ports to *BSD, etc. > > While Sun may not be interested in merging in all such ports into the > main OpenJDK tree, it could be useful to have the patch sets maintained > centrally as part of the OpenJDK infrastructure. The distributed mercurial > setup could give us that liberty, I think. > This sounds like a very usefull thing to do, especially to avoid multiple ports for the same platform. In reality there will be (hopefully) quite a lot of ports and it will be probably unavoidable that multiple ports for a single platform will emerge. (Imagine for example two companies contributing their ports for the same platform which they also distribute under a second, closed licence. So it will be impossible for these companies, to integrate code from the OpenJDK project into their private version.) However a porting group will definitely be a very good place to discuss and to coordinate the different ports. Volker PS: perhaps it would make sense to start a new thread for this topic as it has nothing more to do with Mozilla plugins for AMD64? > cheers, > dalibor topic > From David.Herron at Sun.COM Mon Oct 29 18:02:26 2007 From: David.Herron at Sun.COM (David Herron) Date: Mon, 29 Oct 2007 11:02:26 -0700 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <47260622.1020209@kaffe.org> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> Message-ID: <47262032.1070908@sun.com> Dalibor Topic wrote: > Kurt Miller wrote: >> On Monday 29 October 2007 8:51:11 am Massimo Perga wrote: >>> Hello All, >>> I'm writing here to know what's the best process to follow in >>> order to >>> have more informations on such a plug-in. I'm not requesting it... >>> rather, >>> I'm *offering* to port the current 32-bit Linux version to a native >>> 64-bit >>> version. To accomplish this task, which is the project that takes >>> care of >>> such a plug-in ? Otherwise, have I to request a new project ? >>> >>> Thanks in advance, >>> Regards, >>> Max >> Myself and Jung-uk Kim have completed making the plugin 64-bit >> clean for the 1.6 JRL licensed plugin. You can find our work in patchset >> 2 for BSD: >> >> http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html >> > On an unrelated note, would it make sense to create infrastructure for > the porting projects inside OpenJDK? I am wondering if we shouldn't > create an official 'porters' group, with projects for ports to *BSD, etc. > > While Sun may not be interested in merging in all such ports into the > main OpenJDK tree, it could be useful to have the patch sets maintained > centrally as part of the OpenJDK infrastructure. The distributed > mercurial > setup could give us that liberty, I think. > > cheers, > dalibor topic I'm very much in agreement with any move in this direction. I have a concern which I've heard some people inside Sun speak. Namely: Who will be responsible for the quality of these ports? At the meeting we held at FOSDEM I remember the lecture we had in the operation of the GCC project and how they go about supporting lots of CPU architecture and OS platform combinations. On the one hand I think the OpenJDK has the potential to have that same breadth of platform support. But if it's at the cost of the Sun quality engineering team it will not work. I think hosting a project like this has to be coupled with a plan for maintaining quality in that project. - David Herron From aph at redhat.com Mon Oct 29 18:15:21 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Oct 2007 18:15:21 +0000 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <47262032.1070908@sun.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> <47262032.1070908@sun.com> Message-ID: <18214.9017.61653.815472@zebedee.pink> David Herron writes: > Dalibor Topic wrote: > > Kurt Miller wrote: > > While Sun may not be interested in merging in all such ports into the > > main OpenJDK tree, it could be useful to have the patch sets maintained > > centrally as part of the OpenJDK infrastructure. The distributed > > mercurial > > setup could give us that liberty, I think. > I'm very much in agreement with any move in this direction. > > I have a concern which I've heard some people inside Sun speak. > Namely: Who will be responsible for the quality of these ports? The maintainers of those ports. Who else could possibly do it? Other people may not even have the hardware. > At the meeting we held at FOSDEM I remember the lecture we had in > the operation of the GCC project and how they go about supporting > lots of CPU architecture and OS platform combinations. On the one > hand I think the OpenJDK has the potential to have that same > breadth of platform support. But if it's at the cost of the Sun > quality engineering team it will not work. > > I think hosting a project like this has to be coupled with a plan > for maintaining quality in that project. Why is this any different from any other free software project? The maintainers of each target will make sure it gets built and tested. If the XYZ port of OpenJDK doesn't work, then that's a bug against the XYZ port, and the XYZ maintainers will have to fix it. If the XYZ port isn't being properly maintained it will be deleted from the source tree. If the maintainers are good, so will their port be; if not, it won't. If OpenJDK is really to be open it has to be a *distributed* effort, with porting, testing, and support done by independent workers. The Sun QE team can't so do it. And yes, there will be bad ports out there. But you can't stop that: it's free software. The question is whether to ignore the bad ports or try to bring them inside the fold to help the maintainers turn them into good ports. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From kurt at intricatesoftware.com Mon Oct 29 18:49:18 2007 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 29 Oct 2007 14:49:18 -0400 Subject: official 'porters' group In-Reply-To: <47260622.1020209@kaffe.org> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> Message-ID: <47262B2E.2030205@intricatesoftware.com> Dalibor Topic wrote: > Kurt Miller wrote: >> Myself and Jung-uk Kim have completed making the plugin 64-bit >> clean for the 1.6 JRL licensed plugin. You can find our work in patchset >> 2 for BSD: >> >> http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html >> > On an unrelated note, would it make sense to create infrastructure for > the porting projects inside OpenJDK? I am wondering if we shouldn't > create an official 'porters' group, with projects for ports to *BSD, etc. > > While Sun may not be interested in merging in all such ports into the > main OpenJDK tree, it could be useful to have the patch sets maintained > centrally as part of the OpenJDK infrastructure. The distributed mercurial > setup could give us that liberty, I think. Yes the *BSD porting team would like to have our work incorporated upstream at Sun. If it must be keep in separate branch at first or for longer term that is ok too. I'm not familiar with mercurial at all. We've been using cvs. The JDK src is imported into vendor branches, changes are made to support the BSD's and then patchsets are cut by doing diffs against the original src in the vendor branch. In the end we need either a patchset off official Sun sources or a complete source distribution that includes our changes. So long as mercurial can accomplish those needs it would work for us. Regarding the questions about quality: At least compatibility can be maintained if the JavaTest Harness, the JCK tests and documentation are available to the members of the porters group. I think people are going to be surprised at how well Java support on BSD's measures up - especially OpenBSD and FreeBSD which has the most active participants. Regards, -Kurt From mark at klomp.org Mon Oct 29 19:30:18 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 29 Oct 2007 20:30:18 +0100 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <471BB750.4090306@sun.com> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> <471BB750.4090306@sun.com> Message-ID: <1193686218.2983.17.camel@hermans.wildebeest.org> Hi Kelly, On Sun, 2007-10-21 at 13:32 -0700, Kelly O'Hair wrote: > Mark Wielaard wrote: > > 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). > > 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. It isn't that hard. Moving out of CVS is not nice. But most other SCMs are pretty easy to move between. The OpenJDK mercurial repo on http://icedtea.classpath.org/hg/ is kept up to date with the subversion repo completely automatically without any human intervention for example. Cheers, Mark From Kelly.Ohair at Sun.COM Mon Oct 29 20:44:24 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 29 Oct 2007 13:44:24 -0700 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <1193686218.2983.17.camel@hermans.wildebeest.org> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> <471BB750.4090306@sun.com> <1193686218.2983.17.camel@hermans.wildebeest.org> Message-ID: <47264628.8020901@sun.com> But the granularity of the change history is incomplete between the OpenJDK subversion and icedtea mercurial repositories. All information about who made a change or why the change was made has been lost in the subversion repository, all you have are all the changes made between promotions, all munged together with no changesets for bug fixes or feature additions. Accurate SCM changesets should record the correct date/time the changeset was created, and by who, and include the specific comments added by the engineer making the change. This is difficult to get right when transitioning history between SCM's. -kto Mark Wielaard wrote: > Hi Kelly, > > On Sun, 2007-10-21 at 13:32 -0700, Kelly O'Hair wrote: >> Mark Wielaard wrote: >>> 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). >> 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. > > It isn't that hard. Moving out of CVS is not nice. But most other SCMs > are pretty easy to move between. The OpenJDK mercurial repo on > http://icedtea.classpath.org/hg/ is kept up to date with the subversion > repo completely automatically without any human intervention for > example. > > Cheers, > > Mark > From mark at klomp.org Mon Oct 29 21:29:24 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 29 Oct 2007 22:29:24 +0100 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: <1193693365.12687.9.camel@hermans.wildebeest.org> Hi Phil, On Wed, 2007-10-24 at 09:25 -0700, Phil Race wrote: > Mark Wielaard wrote: > > 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. Sure, as long as email is send even if people use the webrev application so that there is a public record of the review process that can be easily archived. Personally I would like patches by email since that makes it easy to review and comment even when offline. > 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. How does that work with volunteers? You cannot force people to review if they don't actually have time immediately for your particular patch can you? > 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. Interesting. How do people keep a general idea about progress in the whole project then? I admit to not always read all patches on all the patches mailinglists I am subscribed to. But I do read most of them at least casually to get a feeling for what parts of the project are working on. I am not pretending I actually understand them all of course, but it is a nice way to keep your knowledge up to date. > What does "ping their patches" mean? Send a reminder to the list and/or reviewers that a patch is still waiting for more comments. > > 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, That is good to hear! Looking forward to that. Cheers, Mark From mark at klomp.org Mon Oct 29 21:33:35 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 29 Oct 2007 22:33:35 +0100 Subject: Project proposal: Multi-Language VM In-Reply-To: <471FC015.8090200@kaffe.org> References: <471FC015.8090200@kaffe.org> Message-ID: <1193693616.12687.13.camel@hermans.wildebeest.org> On Wed, 2007-10-24 at 23:58 +0200, Dalibor Topic wrote: > John Rose wrote: > > 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]. > > > there hasn't been much discussion of your proposal on discuss at openjdk (I > presume because it's the obviously right thing to do (TM) :) so I just > wanted to pop in and say that I love the idea, and I'd be very happy to > see such a project being developed inside OpenJDK. Yes, Dalibor is right. I don't know why not more people spoke up to support this idea. Maybe nobody knew what more to say because it is such an obviously good idea! :) Cheers, Mark From Phil.Race at Sun.COM Mon Oct 29 21:45:33 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 29 Oct 2007 14:45:33 -0700 Subject: Publishing code reviews In-Reply-To: <1193693365.12687.9.camel@hermans.wildebeest.org> 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> <1193693365.12687.9.camel@hermans.wildebeest.org> Message-ID: <4726547D.3060705@sun.com> Mark Wielaard wrote: > >> 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. >> > > How does that work with volunteers? You cannot force people to review if > they don't actually have time immediately for your particular patch can > you? > And this is why I wanted to highlight it. I don't know how its going to work. When you have busy people sometimes you need to be direct that they are the ones you need to review this, and if you have no idea if they are on a three week vacation in the Australian outback that's a problem if you need to putback before the next build. So perhaps an amalgam where you need at least two reviewers and whilst one must be Fred, where Fred is someone you know is both available and qualified. Perhaps for some stuff literally anyone who can read java code would do .. > >> 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. >> > > Interesting. How do people keep a general idea about progress in the > whole project then? I admit to not always read all patches on all the > patches mailinglists I am subscribed to. But I do read most of them at > least casually to get a feeling for what parts of the project are > working on. I am not pretending I actually understand them all of > course, but it is a nice way to keep your knowledge up to date. > We see bug update emails, putback emails (with links to the webrevs if you are interested) In short, a summary and you can go read the details if you want. >> I'd really like to see updates to bugs emailed out .. hopefully soon, >> > > That is good to hear! Looking forward to that. > Still hoping, but its an uphill struggle .. always one more obstacle .. -phil. From mark at klomp.org Mon Oct 29 21:47:35 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 29 Oct 2007 22:47:35 +0100 Subject: jdk-collaboration forum In-Reply-To: <22ec15240710290344v1d4fcae6ne712218085c4336f@mail.gmail.com> References: <22ec15240710290344v1d4fcae6ne712218085c4336f@mail.gmail.com> Message-ID: <1193694459.12687.25.camel@hermans.wildebeest.org> Hi Matthias, On Mon, 2007-10-29 at 11:44 +0100, Matthias Ernst wrote: > I've posted three messages over a week ago on the collaboration forum, > including one about its relation to the openjdk mailing lists. There > was no answer, and it seems to indicate that jdk-collaboration is > effectively dead and has been replaced by openjdk. > > Is that right and should someone announce that on / shut down jdk-collaboration? I have to admit that I don't actually know what/where the jdk-collaboration forum is. If it is about collaborating on the code base that is now part of OpenJDK I think it is a good idea to try and merge these mailinglists/forums. Please do post your messages on this mailinglist and we will see if we can help. Cheers, Mark From mark at klomp.org Mon Oct 29 21:52:02 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 29 Oct 2007 22:52:02 +0100 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: <706832.48951.qm@web27813.mail.ukl.yahoo.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> Message-ID: <1193694722.12687.30.camel@hermans.wildebeest.org> Hi Massimo, On Mon, 2007-10-29 at 12:51 +0000, Massimo Perga wrote: > I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in. > I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version. > To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ? You might want to try the plugin from IcedTea which is based on OpenJDK and gcjwebplugin. It works great for me on x86 and x86_64. See http://icedtea.classpath.org/ it should also be packaged for the latest Fedora (8) and Ubuntu (Gutsy) releases. Most discussion about it is done on the GNU/Linux distro package list: http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev Cheers, Mark From John.Rose at Sun.COM Mon Oct 29 21:57:27 2007 From: John.Rose at Sun.COM (John Rose) Date: Mon, 29 Oct 2007 14:57:27 -0700 Subject: Project proposal: Multi-Language VM In-Reply-To: <1193693616.12687.13.camel@hermans.wildebeest.org> References: <471FC015.8090200@kaffe.org> <1193693616.12687.13.camel@hermans.wildebeest.org> Message-ID: Thanks for the vote of confidence! The process gears are actually turning: The openjdk/hotspot Group is finishing a vote. I expect to open the workspace, probably with a small sample change, a week or two after the main mercurial workspace looks lively. Regards, -- John On Oct 29, 2007, at 2:33 PM, Mark Wielaard wrote: > On Wed, 2007-10-24 at 23:58 +0200, Dalibor Topic wrote: >> John Rose wrote: >>> 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]. >>> >> there hasn't been much discussion of your proposal on >> discuss at openjdk (I >> presume because it's the obviously right thing to do (TM) :) so I >> just >> wanted to pop in and say that I love the idea, and I'd be very >> happy to >> see such a project being developed inside OpenJDK. > > Yes, Dalibor is right. I don't know why not more people spoke up to > support this idea. Maybe nobody knew what more to say because it is > such > an obviously good idea! :) > > Cheers, > > Mark > From David.Herron at Sun.COM Mon Oct 29 23:37:49 2007 From: David.Herron at Sun.COM (David Herron) Date: Mon, 29 Oct 2007 16:37:49 -0700 Subject: jdk-collaboration forum In-Reply-To: <1193694459.12687.25.camel@hermans.wildebeest.org> References: <22ec15240710290344v1d4fcae6ne712218085c4336f@mail.gmail.com> <1193694459.12687.25.camel@hermans.wildebeest.org> Message-ID: <47266ECD.2070301@sun.com> Mark Wielaard wrote: > Hi Matthias, > > On Mon, 2007-10-29 at 11:44 +0100, Matthias Ernst wrote: > >> I've posted three messages over a week ago on the collaboration forum, >> including one about its relation to the openjdk mailing lists. There >> was no answer, and it seems to indicate that jdk-collaboration is >> effectively dead and has been replaced by openjdk. >> >> Is that right and should someone announce that on / shut down jdk-collaboration? >> > > I have to admit that I don't actually know what/where the > jdk-collaboration forum is. If it is about collaborating on the code > base that is now part of OpenJDK I think it is a good idea to try and > merge these mailinglists/forums. Please do post your messages on this > mailinglist and we will see if we can help. > > Cheers, > > Mark He's referring to http://jdk-collaboration.dev.java.net I do believe the purpose for that project has been superseded by the OpenJDK. But that's really a question for Tom Marble or Ray Gans to answer. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Kessler at Sun.COM Tue Oct 30 00:13:34 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 29 Oct 2007 17:13:34 -0700 Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual Machine In-Reply-To: <471FD7A3.1010806@Sun.COM> References: <471FD7A3.1010806@Sun.COM> Message-ID: <4726772E.4080004@Sun.COM> The Multi-Language Virtual Machine project is approved by a unanimous vote. For the historians: 8 people voted in favor of the MLVM project, 6 of whom can be considered Members of the HotSpot group. No one opposed the formation of the project. A couple of people sent me mail asking how the voting was going. ... peter Peter B. Kessler wrote: > On Oct 9 14:27:22 PDT 2007 John Rose proposed a multi-language > virtual machine project[1] to be hosted by the HotSpot group. > > It's time to vote: Should the HotSpot Group sponsor this Project? > > Please cast your vote by replying to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. Your reply should go to me, > Peter.Kessler at Sun.COM, as I'm the current HotSpot group moderator. > That should happen if you reply to this message. > > You may indicate the reason for your decision, if you wish, on > subsequent lines. You need not give a reason for your vote. > > Votes are due by Oct 29 12:00:00 PDT 2007 (1900 UTC). That's this > coming Monday. I will tally the votes and post a summary to this > list and to discuss at openjdk.java.net. > > Only Members of the HotSpot Group are eligible to vote on this > proposal[2]. At this early date, that means engineers on the Sun > HotSpot project. > > ... peter > > [1] http://mail.openjdk.java.net/pipermail/announce/2007-October/000016.html > [2] http://blogs.sun.com/mr/entry/cosmology From mr at sun.com Tue Oct 30 04:40:31 2007 From: mr at sun.com (Mark Reinhold) Date: Mon, 29 Oct 2007 21:40:31 -0700 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: aph@redhat.com; Mon, 29 Oct 2007 18:15:21 -0000; <18214.9017.61653.815472@zebedee.pink> Message-ID: <20071030044031.90EBA313@callebaut.niobe.net> > Date: Mon, 29 Oct 2007 18:15:21 +0000 > From: Andrew Haley > ... > > Why is this any different from any other free software project? The > maintainers of each target will make sure it gets built and tested. > > If the XYZ port of OpenJDK doesn't work, then that's a bug against the > XYZ port, and the XYZ maintainers will have to fix it. If the XYZ > port isn't being properly maintained it will be deleted from the > source tree. > > If the maintainers are good, so will their port be; if not, it won't. > If OpenJDK is really to be open it has to be a *distributed* effort, > with porting, testing, and support done by independent workers. The > Sun QE team can't so do it. Exactly so. I completely agree that there needs to be a way for ports other than those supported directly by Sun to become part of the main JDK 7 (and 6) source trees in OpenJDK. We'll need to figure out how to identify them as such, and what the policy is for deleting inactive or broken ports, but there are plenty of good examples (e.g., the GCC project) from which to learn. I'm not sure that a general "Porters" Group is the optimal route; such a Group would, I suspect, tend to lack focus. What may make more sense is for each specific porting effort (e.g., BSD) to propose its own Project into which the relevant code can initially be contributed, synced with the mainline code, and generally hacked upon until it's ready to be proposed for integration. Once that integration happens then further development and maintenance of the port would be done under the aegis of the appropriate mainline project (e.g., JDK 7). - Mark From mark at klomp.org Tue Oct 30 11:14:12 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 30 Oct 2007 12:14:12 +0100 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <47264628.8020901@sun.com> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> <471BB750.4090306@sun.com> <1193686218.2983.17.camel@hermans.wildebeest.org> <47264628.8020901@sun.com> Message-ID: <1193742852.3801.19.camel@dijkstra.wildebeest.org> Hi Kelly, On Mon, 2007-10-29 at 13:44 -0700, Kelly O'Hair wrote: > But the granularity of the change history is incomplete between the > OpenJDK subversion and icedtea mercurial repositories. The granularity is the same between the systems. The Mercurial repository contains the exact same change history as the subversion repo. > All information about who made a change or why the change was made > has been lost in the subversion repository, all you have are all the changes > made between promotions, all munged together with no changesets for bug > fixes or feature additions. Sure, but that is all we hackers have for the moment. If the other SCM doesn't provide more information than that then that is what we have to work with. It is still useful information if you are searching for changes between openjdk b[x] and b[y] to track down a bug introduced between versions. > Accurate SCM changesets should record the correct date/time the changeset > was created, and by who, and include the specific comments added by the > engineer making the change. This is difficult to get right when transitioning > history between SCM's. I don't believe it is that hard to transition history between SCMs. At least not if it is between modern ones like subversion and mercurial (CVS is explicitly excluded). Yes, incomplete information in, means incomplete information out. If you could introduce that extra information into the subversion repo it is easy to pick it up in the mercurial repo. If not, then we manage with what we have. All I am saying is that incomplete information is better than no information if you are tracking down stuff in your SCM of choice, whether it is subversion, mercurial or something else. Cheers, Mark From mark at klomp.org Tue Oct 30 11:23:39 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 30 Oct 2007 12:23:39 +0100 Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual Machine In-Reply-To: <4726772E.4080004@Sun.COM> References: <471FD7A3.1010806@Sun.COM> <4726772E.4080004@Sun.COM> Message-ID: <1193743419.3801.24.camel@dijkstra.wildebeest.org> Hi Peter, On Mon, 2007-10-29 at 17:13 -0700, Peter B. Kessler wrote: > The Multi-Language Virtual Machine project is approved by a > unanimous vote. Cool! Looking forward to this. > For the historians: 8 people voted in favor of the MLVM project, > 6 of whom can be considered Members of the HotSpot group. Do you have a list of people "whom can be considered Members"? And should we just make them official Members to bootstrap things a little? Cheers, Mark From Kelly.Ohair at Sun.COM Tue Oct 30 18:23:11 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 30 Oct 2007 11:23:11 -0700 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <1193742852.3801.19.camel@dijkstra.wildebeest.org> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> <471BB750.4090306@sun.com> <1193686218.2983.17.camel@hermans.wildebeest.org> <47264628.8020901@sun.com> <1193742852.3801.19.camel@dijkstra.wildebeest.org> Message-ID: <4727768F.2010805@sun.com> Mark Wielaard wrote: > Hi Kelly, > > On Mon, 2007-10-29 at 13:44 -0700, Kelly O'Hair wrote: >> But the granularity of the change history is incomplete between the >> OpenJDK subversion and icedtea mercurial repositories. > > The granularity is the same between the systems. The Mercurial > repository contains the exact same change history as the subversion > repo. Which is not what is in the TeamWare workspaces we had used, up until Build 23 ;^) > >> All information about who made a change or why the change was made >> has been lost in the subversion repository, all you have are all the changes >> made between promotions, all munged together with no changesets for bug >> fixes or feature additions. > > Sure, but that is all we hackers have for the moment. If the other SCM > doesn't provide more information than that then that is what we have to > work with. It is still useful information if you are searching for > changes between openjdk b[x] and b[y] to track down a bug introduced > between versions. Understood. > >> Accurate SCM changesets should record the correct date/time the changeset >> was created, and by who, and include the specific comments added by the >> engineer making the change. This is difficult to get right when transitioning >> history between SCM's. > > I don't believe it is that hard to transition history between SCMs. At > least not if it is between modern ones like subversion and mercurial > (CVS is explicitly excluded). Yes, incomplete information in, means > incomplete information out. If you could introduce that extra > information into the subversion repo it is easy to pick it up in the > mercurial repo. If not, then we manage with what we have. > > All I am saying is that incomplete information is better than no > information if you are tracking down stuff in your SCM of choice, > whether it is subversion, mercurial or something else. For the state of the source files, I can see your point, but most of the developers I talked to did not consider just having the granularity of per build changes (promotion or weekly or biweekly snapshots) to be enough. They wanted to know who made a change, and what specific revision of a file changed a line, and exactly when that change was created. They wanted details. To them, change history was not change history without those details. Having that level of detail, and also having correct source snapshot views that mesh well with those detailed changes is not impossible, and may indeed be easier with newer SCMs, but it is not simple to get all the details accurate. And TeamWare did present some major problems being a relatively loose collection of separately managed SCCS files. Some of the major changes made in Build 20, 21, and 22 involved massive file movements out of the j2se workspace (soon to be called "jdk"), and into separately managed workspaces for langtools, corba, jaxp and jaxws. Each of these TeamWare workspaces would/have become independent repositories, but part of the jdk forest of repositories. We did that movement BEFORE creating the Mercurial repositories because we didn't want to create initial repositories just to turn right around and delete 10,000 files from the repository, because even though deleted, they would continue to live on in the repository as part of the initial changesets. So our Build 24 repositories will start out fresh, with no history, because any accurate history (even build promotion history) would inflate the repositories just for the sake of that history. People may ask why we didn't just create one big workspace or repository for the entire jdk, and that's a good question. But it came down to being able to separately manage and perhaps independently deliver, various components of the jdk. That decision to create a forest rather than one big repository may come back to haunt me, which if we release our repositories on Halloween maybe I should be haunted. :^( -kto > > Cheers, > > Mark > From Peter.Kessler at Sun.COM Tue Oct 30 20:29:49 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 30 Oct 2007 13:29:49 -0700 Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual Machine In-Reply-To: <1193743419.3801.24.camel@dijkstra.wildebeest.org> References: <471FD7A3.1010806@Sun.COM> <4726772E.4080004@Sun.COM> <1193743419.3801.24.camel@dijkstra.wildebeest.org> Message-ID: <4727943D.1020908@Sun.COM> Mark Wielaard wrote: > Hi Peter, > > On Mon, 2007-10-29 at 17:13 -0700, Peter B. Kessler wrote: >> The Multi-Language Virtual Machine project is approved by a >> unanimous vote. > > Cool! Looking forward to this. > >> For the historians: 8 people voted in favor of the MLVM project, >> 6 of whom can be considered Members of the HotSpot group. > > Do you have a list of people "whom can be considered Members"? > And should we just make them official Members to bootstrap things a > little? > > Cheers, > > Mark Those voting in favor of the Multi-Language Virtual Machine project were: Peter Kessler Tom Rodriguez Dave Cox John Coomes John Rose Tony Printezis Raja Reddy Oscar Victorio Calixto Bacho No one voted against the project. My understanding is that the current Members of the HotSpot Group are the members of Sun's HotSpot engineering team. That includes the first 6 people on the list above. If that's wrong, I expect to be corrected by the IGB. ... peter From robilad at kaffe.org Tue Oct 30 20:48:42 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 30 Oct 2007 21:48:42 +0100 Subject: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform In-Reply-To: References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> Message-ID: <472798AA.3040102@kaffe.org> Volker Simonis wrote: > PS: perhaps it would make sense to start a new thread for this topic > as it has nothing more to do with Mozilla plugins for AMD64? Yeah, let's continue under the maintaining ports thread. cheers, dalibor topic From Weijun.Wang at Sun.COM Wed Oct 31 00:06:38 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Wed, 31 Oct 2007 08:06:38 +0800 Subject: JDK 7 moving to mercurial -- svn repositories In-Reply-To: <4727768F.2010805@sun.com> References: <470A65EB.2040009@Sun.COM> <470B713D.40003@kaffe.org> <1191946808.12606.15.camel@gloria> <470BDD1A.4060908@Sun.COM> <1192919103.9521.68.camel@localhost.localdomain> <471BB750.4090306@sun.com> <1193686218.2983.17.camel@hermans.wildebeest.org> <47264628.8020901@sun.com> <1193742852.3801.19.camel@dijkstra.wildebeest.org> <4727768F.2010805@sun.com> Message-ID: I think Kelly and some other guys have done a lot of experiments on how to turn Teamware histories into Mercurial changesets (this even reminds him of being a math graduate long time ago). Unfortunately it seems there's not a perfect solution. Yes, throwing away the history of OpenJDK before b23 is not something to boast on, but, let's expect that comparing to the huge contributions from all Sun and non-Sun developers after b24, the changes before b23 is only a tiny except of the long history/future of OpenJDK. We won't lost much. If someone really want to look into there, for archive or memorial purpose, the current OpenJDK Mercurial repository managed by IcedTea can stay forever. Max On Oct 31, 2007, at 2:23 AM, Kelly O'Hair wrote: > > > Mark Wielaard wrote: >> Hi Kelly, >> On Mon, 2007-10-29 at 13:44 -0700, Kelly O'Hair wrote: >>> But the granularity of the change history is incomplete between the >>> OpenJDK subversion and icedtea mercurial repositories. >> The granularity is the same between the systems. The Mercurial >> repository contains the exact same change history as the subversion >> repo. > > Which is not what is in the TeamWare workspaces we had used, up > until Build 23 ;^) > >>> All information about who made a change or why the change was made >>> has been lost in the subversion repository, all you have are all >>> the changes >>> made between promotions, all munged together with no changesets >>> for bug >>> fixes or feature additions. >> Sure, but that is all we hackers have for the moment. If the other >> SCM >> doesn't provide more information than that then that is what we >> have to >> work with. It is still useful information if you are searching for >> changes between openjdk b[x] and b[y] to track down a bug introduced >> between versions. > > Understood. > >>> Accurate SCM changesets should record the correct date/time the >>> changeset >>> was created, and by who, and include the specific comments added >>> by the >>> engineer making the change. This is difficult to get right when >>> transitioning >>> history between SCM's. >> I don't believe it is that hard to transition history between >> SCMs. At >> least not if it is between modern ones like subversion and mercurial >> (CVS is explicitly excluded). Yes, incomplete information in, means >> incomplete information out. If you could introduce that extra >> information into the subversion repo it is easy to pick it up in the >> mercurial repo. If not, then we manage with what we have. >> All I am saying is that incomplete information is better than no >> information if you are tracking down stuff in your SCM of choice, >> whether it is subversion, mercurial or something else. > > For the state of the source files, I can see your point, but most > of the > developers I talked to did not consider just having the granularity of > per build changes (promotion or weekly or biweekly snapshots) to be > enough. > They wanted to know who made a change, and what specific revision > of a file > changed a line, and exactly when that change was created. They > wanted details. > To them, change history was not change history without those details. > Having that level of detail, and also having correct source > snapshot views > that mesh well with those detailed changes is not impossible, and > may indeed > be easier with newer SCMs, but it is not simple to get all the > details accurate. > And TeamWare did present some major problems being a relatively > loose collection > of separately managed SCCS files. > > Some of the major changes made in Build 20, 21, and 22 involved > massive file > movements out of the j2se workspace (soon to be called "jdk"), and > into > separately managed workspaces for langtools, corba, jaxp and jaxws. > Each of these TeamWare workspaces would/have become independent > repositories, > but part of the jdk forest of repositories. > We did that movement BEFORE creating the Mercurial repositories > because we > didn't want to create initial repositories just to turn right > around and delete > 10,000 files from the repository, because even though deleted, they > would > continue to live on in the repository as part of the initial > changesets. > > So our Build 24 repositories will start out fresh, with no history, > because > any accurate history (even build promotion history) would inflate the > repositories just for the sake of that history. > > People may ask why we didn't just create one big workspace or > repository > for the entire jdk, and that's a good question. But it came down to > being able > to separately manage and perhaps independently deliver, various > components > of the jdk. That decision to create a forest rather than one big > repository > may come back to haunt me, which if we release our repositories on > Halloween > maybe I should be haunted. :^( > > -kto > >> Cheers, >> Mark From robilad at kaffe.org Wed Oct 31 14:18:13 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 31 Oct 2007 15:18:13 +0100 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: <20071030044031.90EBA313@callebaut.niobe.net> References: <20071030044031.90EBA313@callebaut.niobe.net> Message-ID: <47288EA5.1050704@kaffe.org> Mark Reinhold wrote: > I'm not sure that a general "Porters" Group is the optimal route; such a > Group would, I suspect, tend to lack focus. What may make more sense is > for each specific porting effort (e.g., BSD) to propose its own Project > into which the relevant code can initially be contributed, synced with > the mainline code, and generally hacked upon until it's ready to be > proposed for integration. Once that integration happens then further > development and maintenance of the port would be done under the aegis > of the appropriate mainline project (e.g., JDK 7). > I think 'lack of focus' is a general issue when porting OpenJDK, as depending on the configuration one is porting to, one needs to work on many different components. A porters group would seem to be a good place to group different projects together that have at least one thing in common: they aren't going to be supported as part of the mainline QA work by Sun, but, as you said, can serve as 'staging ground' for code & fixes destined to go upstream into mainline, coming from different porting communities. I see a couple of benefits to such a structure: the porting efforts can use our bug tracking, repository, review and legal (SCA) infrastructure, which should make merging in their fixes and features into the mainline project much easier. It would also allow us to formally recognize such projects as parts of the OpenJDK community, and the contributors channeling their contributions through the porting projects would know that their patches contribute to OpenJDK, even if the actual merging and review process into mainline, once a contribution has entered via a porting project, takes a while to ensure the high standards necessary for code coming into the OpenJDK core. Finally, grouping porting projects together would also serve as a tiny demarcation line between parts of OpenJDK that are officially part of the mainline jdk7, and porting efforts that are not (yet). Chances are that some porting efforts will never be worth the monetary investment in QA it would take to make them non-academic in nature. But that's OK, they still may end up doing useful work on other components of OpenJDK as part of their efforts, and as long as they are not a drain on our resources, I'd rather have them inside OpenJDK, than outside. I'd expect us to mirror part of the project roster of the 'porters' group inside the conformance group, so I guess we may as well group them all together formally. :) cheers, dalibor topic From robilad at kaffe.org Wed Oct 31 14:51:52 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 31 Oct 2007 15:51:52 +0100 Subject: JDK 7 build 23 is available at the openjdk.java.net website In-Reply-To: <4727C8D4.8020108@Sun.COM> References: <4727C8D4.8020108@Sun.COM> Message-ID: <47289688.9000006@kaffe.org> Xiomara.Jayasena at Sun.COM wrote: > > The OpenJDK source and Jtreg binary for the promoted JDK 7 build b23 > is available under the openjdk http://openjdk.java.net website under > Source Code (direct link to bundles: > http://download.java.net/openjdk/jdk7 ) > > The OpenJDK sources are also available at the subversion repository > http://openjdk.dev.java.net/source/browse/openjdk > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b23.html > > Thanks, > -Xiomara For people who can't see the changes yet for some odd reason or another: Bugs fixed current JDK7 build b23 *Category* *ID* *Synopsis* *hotspot:compiler2* 6616627 64-bit j2se build problem: ArrayIndexOutOfBoundsException: -2147483521 *hotspot:other* 6621863 Merged @test and @bug lines *java:build* 6617210 jaxws GPL comments missing 6619248 jaxws back out incomplete 6621156 Change use of name JDK_TOPDIR in linux install makefiles to JDK_RPM_TEMPDIR 6621680 SCCS keyword issue with corba files *java:specification* 6471750 JVMS3 4.4.4 Bug in Signature Grammar in revisions to "The class File Format" document New features integrated current JDK7 build b23 *Category* *ID* *Synopsis* *doctools:genhtml* 6559429 genhtml corrupts european extended characters in xml *java:build* 6594527 Change/remove references of the name "j2se" 6616089 Whitespace cleanup on all sources 6622299 Top level README files need more information cheers, dalibor topic From robilad at kaffe.org Wed Oct 31 15:02:51 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 31 Oct 2007 16:02:51 +0100 Subject: official 'porters' group In-Reply-To: <47262B2E.2030205@intricatesoftware.com> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> <47262B2E.2030205@intricatesoftware.com> Message-ID: <4728991B.9030804@kaffe.org> Kurt Miller wrote: > Yes the *BSD porting team would like to have our work incorporated > upstream at Sun. If it must be keep in separate branch at first > or for longer term that is ok too. > > Great, we're all on the same page, I think. > I'm not familiar with mercurial at all. We've been using cvs. The > JDK src is imported into vendor branches, changes are made to > support the BSD's and then patchsets are cut by doing diffs > against the original src in the vendor branch. In the end we > need either a patchset off official Sun sources or a complete > source distribution that includes our changes. So long as > mercurial can accomplish those needs it would work for us. > I've CC:ed Mark Wielaard on this to see if what we are doing on the icedtea mercurial repository is similar. I hope he can provide some insight, he mentioned "mercurial queues" on IRC after being poked around by me. :) cheers, dalibor topic From mark at klomp.org Wed Oct 31 15:15:09 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 31 Oct 2007 16:15:09 +0100 Subject: official 'porters' group In-Reply-To: <4728991B.9030804@kaffe.org> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> <47262B2E.2030205@intricatesoftware.com> <4728991B.9030804@kaffe.org> Message-ID: <1193843709.3736.12.camel@dijkstra.wildebeest.org> Hi Dalibor, Hi Kurt, On Wed, 2007-10-31 at 16:02 +0100, Dalibor Topic wrote: > Kurt Miller wrote: > > I'm not familiar with mercurial at all. We've been using cvs. The > > JDK src is imported into vendor branches, changes are made to > > support the BSD's and then patchsets are cut by doing diffs > > against the original src in the vendor branch. In the end we > > need either a patchset off official Sun sources or a complete > > source distribution that includes our changes. So long as > > mercurial can accomplish those needs it would work for us. > > > I've CC:ed Mark Wielaard on this to see if what we are doing on the > icedtea mercurial repository is similar. > I hope he can provide some insight, he mentioned "mercurial queues" on > IRC after being poked > around by me. :) Actually I said we aren't doing it yet for IcedTea :) But we really should when the switch to mercurial is completed. Mercurial Queues is pretty nice for keeping patch sets on top of an upstream mercurial repo. You can even keep and publish the patchsets in their own mercurial repo so you can collaboratively work on them. You pull your patches when you refresh the mercurial tree from upstream and then push them again to rebase. MQ knows about the whole mercurial way of managing files so it is as if you are working on the actual tree while still keeping your patchsets separate. There is some very nice documentation about it at: http://hgbook.red-bean.com/hgbookch12.html "Managing change with Mercurial Queues" from "Distributed revision control with Mercurial" by Bryan O'Sullivan which is highly recommended. Cheers, Mark From robilad at kaffe.org Wed Oct 31 15:16:06 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 31 Oct 2007 16:16:06 +0100 Subject: official 'porters' group In-Reply-To: <1193843709.3736.12.camel@dijkstra.wildebeest.org> References: <706832.48951.qm@web27813.mail.ukl.yahoo.com> <200710291022.31911.kurt@intricatesoftware.com> <47260622.1020209@kaffe.org> <47262B2E.2030205@intricatesoftware.com> <4728991B.9030804@kaffe.org> <1193843709.3736.12.camel@dijkstra.wildebeest.org> Message-ID: <47289C36.80906@kaffe.org> Mark Wielaard wrote: > Hi Dalibor, Hi Kurt, > > On Wed, 2007-10-31 at 16:02 +0100, Dalibor Topic wrote: > >> Kurt Miller wrote: >> >>> I'm not familiar with mercurial at all. We've been using cvs. The >>> JDK src is imported into vendor branches, changes are made to >>> support the BSD's and then patchsets are cut by doing diffs >>> against the original src in the vendor branch. In the end we >>> need either a patchset off official Sun sources or a complete >>> source distribution that includes our changes. So long as >>> mercurial can accomplish those needs it would work for us. >>> >>> >> I've CC:ed Mark Wielaard on this to see if what we are doing on the >> icedtea mercurial repository is similar. >> I hope he can provide some insight, he mentioned "mercurial queues" on >> IRC after being poked >> around by me. :) >> > > Actually I said we aren't doing it yet for IcedTea :) But we really > should when the switch to mercurial is completed. > > Mercurial Queues is pretty nice for keeping patch sets on top of an > upstream mercurial repo. You can even keep and publish the patchsets in > their own mercurial repo so you can collaboratively work on them. You > pull your patches when you refresh the mercurial tree from upstream and > then push them again to rebase. MQ knows about the whole mercurial way > of managing files so it is as if you are working on the actual tree > while still keeping your patchsets separate. There is some very nice > documentation about it at: http://hgbook.red-bean.com/hgbookch12.html > "Managing change with Mercurial Queues" from "Distributed revision > control with Mercurial" by Bryan O'Sullivan which is highly recommended. > > thank you very much, Mark! cheers, dalibor topic From amitksaha at netbeans.org Wed Oct 31 15:18:23 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Wed, 31 Oct 2007 20:48:23 +0530 Subject: How does IcedTea plugging work? Message-ID: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> Hello all! It would really be nice, if someone could provide me with a brief idea about how IcedTea has been developed. Specifically, I would like to know- if i have my own Open JDK build and i want to plugin the GNU classpath packages - how would I do that? Thanks in advance. Regards, Amit -- Amit Kumar Saha *NetBeans Community Docs Contribution Coordinator* me blogs@ http://amitksaha.blogspot.com URL:http://amitsaha.in.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Oct 31 15:48:53 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 31 Oct 2007 15:48:53 +0000 Subject: How does IcedTea plugging work? In-Reply-To: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> References: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> Message-ID: <18216.41957.444562.830463@zebedee.pink> Amit Kumar Saha writes: > It would really be nice, if someone could provide me with a brief idea about > how IcedTea has been developed. > > Specifically, I would like to know- if i have my own Open JDK build and i > want to plugin the GNU classpath packages - how would I do that? Which GNU classpath packages? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From kurt at intricatesoftware.com Wed Oct 31 15:51:37 2007 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 31 Oct 2007 11:51:37 -0400 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: <47288EA5.1050704@kaffe.org> References: <20071030044031.90EBA313@callebaut.niobe.net> <47288EA5.1050704@kaffe.org> Message-ID: <4728A489.1080308@intricatesoftware.com> Dalibor Topic wrote: > Mark Reinhold wrote: >> I'm not sure that a general "Porters" Group is the optimal route; such a >> Group would, I suspect, tend to lack focus. What may make more sense is >> for each specific porting effort (e.g., BSD) to propose its own Project >> into which the relevant code can initially be contributed, synced with >> the mainline code, and generally hacked upon until it's ready to be >> proposed for integration. Once that integration happens then further >> development and maintenance of the port would be done under the aegis >> of the appropriate mainline project (e.g., JDK 7). >> > > I think 'lack of focus' is a general issue when porting OpenJDK, as > depending on the configuration one is porting to, one needs to work > on many different components. A porters group would seem to be > a good place to group different projects together that have at least one > thing in common: they aren't going to be supported as part of the > mainline QA work by Sun, but, as you said, can serve as 'staging > ground' for code & fixes destined to go upstream into mainline, > coming from different porting communities. > > I see a couple of benefits to such a structure: the porting efforts can > use our bug tracking, repository, review and legal (SCA) infrastructure, > which should make merging in their fixes and features into the > mainline project much easier. It would also allow us to formally > recognize such projects as parts of the OpenJDK community, > and the contributors channeling their contributions through the porting > projects would know that their patches contribute to OpenJDK, even if > the actual merging and review process into mainline, once a > contribution has entered via a porting project, takes a while to > ensure the high standards necessary for code coming into the > OpenJDK core. > > Finally, grouping porting projects together would also serve as a tiny > demarcation line between parts of OpenJDK that are officially part of > the mainline jdk7, and porting efforts that are not (yet). Chances > are that some porting efforts will never be worth the monetary > investment in QA it would take to make them non-academic in nature. > But that's OK, they still may end up doing useful work on other > components of OpenJDK as part of their efforts, and as long as they > are not a drain on our resources, I'd rather have them inside > OpenJDK, than outside. > > I'd expect us to mirror part of the project roster of the 'porters' > group inside the conformance group, so I guess we may as well group > them all together formally. :) > > cheers, > dalibor topic I see the merits of both approaches (single porters group vs specific porters group). I do have some concerns with a single porters group that perhaps can mitigated. The BSD ports are mature ports that have been maintained since 1.1. The needs of a general porters group will likely be a bit different then what the focus of a BSD group would be. I would anticipate new ports would want to discuss and experiment porting the JDK to other platforms, whereas the BSD port is complete and would be focused on improving the quality of the existing port to the point where it could become part of the source tree someday. If there was general porters group but a separate project for the BSD's that might would work too. Ultimately I would want to keep the BSD port source code separate from new (less mature) ports to other platforms. My concern with a mixed source environment would be that new ports would distract from the goal of the BSD port eventually being integrated. Even if BSD integration is never achieved due to other barriers, maintaining and improving the high quality of the BSD port is quite important for us. For the above reasons I tend to favor a BSD specific group and an associated project. The focus of such a group would be well defined and its goals achievable; i.e. ongoing BSD support and maintenance of OpenJDK and the improvement of port quality for some future possible integration with the main source tree. Regards, -Kurt From robilad at kaffe.org Wed Oct 31 16:57:33 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 31 Oct 2007 17:57:33 +0100 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: <4728A489.1080308@intricatesoftware.com> References: <20071030044031.90EBA313@callebaut.niobe.net> <47288EA5.1050704@kaffe.org> <4728A489.1080308@intricatesoftware.com> Message-ID: <4728B3FD.2090004@kaffe.org> Kurt Miller wrote: > If there was general porters group but a separate project for the BSD's > that might would work too. It probably didn't came out as I wanted it, but yeah, the idea I'm toying around with is having a group for porters, and having separate projects for each port (bsd, icedtea [1], ...) with different source repositories as part of that group. Since the current processes are focused around Members, and Members are instantiated by Groups, rather than Projects, for bootstrapping purposes we need some group that can handle member 'creation' for porting projects. We can have one such group, or we can have multiple groups, one for each porting project. Alternatively, we could rely on the contributions of potential members to porting projects to existing projects to become eventually significant enough for existing groups to let them in, and grant them membership status. I'm not quite enthusiastic about that option, because it requires potential members to porting projects to first gain credibility doing something else, before they are allowed to be members of a porting project. cheers, dalibor topic [1] ... for a convenient definition of 'port'. From amitksaha at netbeans.org Wed Oct 31 17:16:19 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Wed, 31 Oct 2007 22:46:19 +0530 Subject: How does IcedTea plugging work? In-Reply-To: <18216.41957.444562.830463@zebedee.pink> References: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> <18216.41957.444562.830463@zebedee.pink> Message-ID: <547db2260710311016x4a9a9379yc768586a988eb08e@mail.gmail.com> On 10/31/07, Andrew Haley wrote: > > Amit Kumar Saha writes: > > > It would really be nice, if someone could provide me with a brief idea > about > > how IcedTea has been developed. > > > > Specifically, I would like to know- if i have my own Open JDK build and > i > > want to plugin the GNU classpath packages - how would I do that? > > Which GNU classpath packages? None in particular. I was wondering if there is a general way of doing it or is it package specific? Its fine if you can just illustrate via a single example. Thanks, Amit -- Amit Kumar Saha *NetBeans Community Docs Contribution Coordinator* me blogs@ http://amitksaha.blogspot.com URL:http://amitsaha.in.googlepages.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at klomp.org Wed Oct 31 21:44:53 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 31 Oct 2007 22:44:53 +0100 Subject: EXPERIMENTAL open repositories live In-Reply-To: <4728EF5F.7030006@sun.com> References: <4728EF5F.7030006@sun.com> Message-ID: <1193867093.3411.12.camel@hermans> On Wed, 2007-10-31 at 14:10 -0700, Kelly O'Hair wrote: > Experimental openjdk repositories! > > http://hg.openjdk.java.net Excellent & Congrats! For those wanting to play with it you need the Mercurial Forest extension: http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension $ hg clone http://www.terminus.org/hg/hgforest And add the following to your ~/.hgrc: [extensions] hgext.forest=/home/mark/src/hgforest/forest.py (With the above path replace with the location you just cloned the forest extension to of course.) Then clone the MASTER repo with hg flcone instead of hg clone: $ hg fclone http://hg.openjdk.java.net/jdk7/MASTER Happy Hacking! Mark P.S Don't forget to read the warning at the top of http://hg.openjdk.java.net/ NOTE: These repositories are EXPERIMENTAL as we work to finalize the details of the Mercurial migration. They will be reinitialized once we're finished, at which point any clones will become unrelated and should be discarded. From Kelly.Ohair at Sun.COM Wed Oct 31 21:49:41 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 31 Oct 2007 14:49:41 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: <1193867093.3411.12.camel@hermans> References: <4728EF5F.7030006@sun.com> <1193867093.3411.12.camel@hermans> Message-ID: <4728F875.6020905@sun.com> Just a note... We discovered that when you do the initial fclone, the destination directory should NOT exist at all, i.e. don't do a mkdir before the fclone. Otherwise the top level files don't show up. -kto Mark Wielaard wrote: > On Wed, 2007-10-31 at 14:10 -0700, Kelly O'Hair wrote: >> Experimental openjdk repositories! >> >> http://hg.openjdk.java.net > > Excellent & Congrats! > > For those wanting to play with it you need the Mercurial Forest > extension: > http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension > > $ hg clone http://www.terminus.org/hg/hgforest > > And add the following to your ~/.hgrc: > > [extensions] > hgext.forest=/home/mark/src/hgforest/forest.py > > (With the above path replace with the location you just cloned the > forest extension to of course.) > > Then clone the MASTER repo with hg flcone instead of hg clone: > > $ hg fclone http://hg.openjdk.java.net/jdk7/MASTER > > Happy Hacking! > > Mark > > P.S Don't forget to read the warning at the top of http://hg.openjdk.java.net/ > > NOTE: These repositories are EXPERIMENTAL as we work to finalize > the details of the Mercurial migration. They will be reinitialized once > we're finished, at which point any clones will become unrelated and > should be discarded. > From Eric.Armstrong at Sun.COM Wed Oct 31 21:52:34 2007 From: Eric.Armstrong at Sun.COM (Eric Armstrong) Date: Wed, 31 Oct 2007 14:52:34 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: <4728EF5F.7030006@sun.com> References: <4728EF5F.7030006@sun.com> Message-ID: <4728F922.1030208@sun.com> Very cool. I don't see a MASTER/pubs workspace, though. Is that planned? Kelly O'Hair wrote: > > Experimental openjdk repositories! > > http://hg.openjdk.java.net > > -kto > -- Eric Armstrong, Document Systems Architect, Sun Microsystems http://blogs.sun.com/coolstuff http://www.artima.com/weblogs/index.jsp?blogger=cooltools From David.Herron at Sun.COM Wed Oct 31 22:03:28 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 31 Oct 2007 15:03:28 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: <1193867093.3411.12.camel@hermans> References: <4728EF5F.7030006@sun.com> <1193867093.3411.12.camel@hermans> Message-ID: <4728FBB0.4020609@sun.com> Mark, you mentioned on IRC that I should email to the list about this. I installed the forest extension the way you described and hg is throwing errors. On the page for the Forest extension it says this:- As of 9/3/2007, the version at this repository does not load or work correctly under Mercurial 0.9.4. Simon is presently consolidating updates, and hopes to have a new version for packaging shortly. --- shap My system is Ubuntu 7.04 and mercurial is 0.9.3. They mention this BatteriesIncluded package but it seems to be an installer for Windows (ick). They do say something about an older version of forest which is still compatible. Any suggestions? BTW, I did find that cloning individual repositories works. That could be a workaround dherron at dherron:~/openjdk/hg$ hg clone http://hg.openjdk.java.net/jdk7/MASTER/corba destination directory: corba requesting all changes adding changesets adding manifests adding file changes added 1 changesets with 1368 changes to 1368 files 1368 files updated, 0 files merged, 0 files removed, 0 files unresolved - David Herron Mark Wielaard wrote: > On Wed, 2007-10-31 at 14:10 -0700, Kelly O'Hair wrote: > >> Experimental openjdk repositories! >> >> http://hg.openjdk.java.net >> > > Excellent & Congrats! > > For those wanting to play with it you need the Mercurial Forest > extension: > http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension > > $ hg clone http://www.terminus.org/hg/hgforest > > And add the following to your ~/.hgrc: > > [extensions] > hgext.forest=/home/mark/src/hgforest/forest.py > > (With the above path replace with the location you just cloned the > forest extension to of course.) > > Then clone the MASTER repo with hg flcone instead of hg clone: > > $ hg fclone http://hg.openjdk.java.net/jdk7/MASTER > > Happy Hacking! > > Mark > > P.S Don't forget to read the warning at the top of http://hg.openjdk.java.net/ > > NOTE: These repositories are EXPERIMENTAL as we work to finalize > the details of the Mercurial migration. They will be reinitialized once > we're finished, at which point any clones will become unrelated and > should be discarded. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at limasoftware.net Wed Oct 31 22:28:05 2007 From: neugens at limasoftware.net (Mario Torre) Date: Wed, 31 Oct 2007 23:28:05 +0100 Subject: How does IcedTea plugging work? In-Reply-To: <547db2260710311016x4a9a9379yc768586a988eb08e@mail.gmail.com> References: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> <18216.41957.444562.830463@zebedee.pink> <547db2260710311016x4a9a9379yc768586a988eb08e@mail.gmail.com> Message-ID: <1193869685.3187.10.camel@nirvana.limasoftware.net> Il giorno mer, 31/10/2007 alle 22.46 +0530, Amit Kumar Saha ha scritto: > > > On 10/31/07, Andrew Haley wrote: > Amit Kumar Saha writes: > > > It would really be nice, if someone could provide me with a > brief idea about > > how IcedTea has been developed. > > > > Specifically, I would like to know- if i have my own Open > JDK build and i > > want to plugin the GNU classpath packages - how would I do > that? > > Which GNU classpath packages? > > None in particular. I was wondering if there is a general way of doing > it or is it package specific? Its fine if you can just illustrate via > a single example. > > Thanks, > Amit It depends on your needs. What we usually do is to prepare a patchset against the current OpenJDK tree, store the patchset into the patch directory of IcedTea, and then enable it into the Makefile. The hard part is to make the patchset itself, especially if you want to add native stuff because OpenJDK uses a different way to build, and it's not always obvious how to do it, so what you need to know depends on what you want to do. For example, I just finished porting the GConf preference backend we have in Classpath into IcedTea. I wanted to keep the ability to enable/disable it at compile time. I had a couple of choices to do this, one was to hack around the different build scripts, adding the sources I needed, the configure time libraries (and I gave up on this), create the patch, and enable/disable it in the IcedTea Makefile. The other (what I did actually) was to just put the backend sources into a directory of its own, use the usual configure/make magics, then copy the shared object into the appropriate places. So, it really depends on your task. Hope that helps, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: