From jesse.glick at sun.com Thu Nov 1 00:21:04 2007 From: jesse.glick at sun.com (Jesse Glick) Date: Wed, 31 Oct 2007 20:21:04 -0400 Subject: EXPERIMENTAL open repositories live In-Reply-To: <4728FBB0.4020609@sun.com> References: <4728EF5F.7030006@sun.com> <1193867093.3411.12.camel@hermans> <4728FBB0.4020609@sun.com> Message-ID: David Herron wrote: > I installed the forest extension the way you described and hg is > throwing errors. [...] My system is Ubuntu 7.04 and mercurial is > 0.9.3. Seems to be working fine for me with Ubuntu 7.10 and mercurial 0.9.4. -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net http://google.com/search?q=e%5E%28pi*i%29%2B1 From mr at sun.com Thu Nov 1 02:38:10 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 31 Oct 2007 19:38:10 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: jesse.glick@sun.com; Wed, 31 Oct 2007 20:21:04 EDT; Message-ID: <20071101023810.C7C40313@callebaut.niobe.net> > Date: Wed, 31 Oct 2007 20:21:04 -0400 > From: jesse.glick at sun.com > David Herron wrote: >> I installed the forest extension the way you described and hg is >> throwing errors. [...] My system is Ubuntu 7.04 and mercurial is >> 0.9.3. > > Seems to be working fine for me with Ubuntu 7.10 and mercurial 0.9.4. We're using Mercurial 0.9.4 on the server. I'm not sure that the current version of the forest extension even works in 0.9.3. David: Suggest upgrading to hg 0.9.4. - Mark From Weijun.Wang at Sun.COM Thu Nov 1 02:59:59 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 01 Nov 2007 10:59:59 +0800 Subject: EXPERIMENTAL open repositories live In-Reply-To: <4728EF5F.7030006@sun.com> References: <4728EF5F.7030006@sun.com> Message-ID: <9D7A2593-B977-43BD-BAB2-4367DAB65972@sun.com> What does it mean EXPERIMENTAL? This seems to be the most official URL I can think of. Thanks Max On Nov 1, 2007, at 5:10 AM, Kelly O'Hair wrote: > > Experimental openjdk repositories! > > http://hg.openjdk.java.net > > -kto > From mr at sun.com Thu Nov 1 03:34:22 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 31 Oct 2007 20:34:22 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: weijun.wang@sun.com; Thu, 01 Nov 2007 10:59:59 +0800; <9D7A2593-B977-43BD-BAB2-4367DAB65972@sun.com> Message-ID: <20071101033422.55F4C313@callebaut.niobe.net> > Date: Thu, 01 Nov 2007 10:59:59 +0800 > From: weijun.wang at sun.com > What does it mean EXPERIMENTAL? This seems to be the most official > URL I can think of. The URL is official; the contents are not -- yet. We're going to do some dry-run integrations over the next week or so in order to identify any kinks in the infrastructure -- and in our integrators' understanding of Mercurial. During this time various pointless changesets will be pushed up into the MASTER forest. When we're done with that exercise we'll reinitialize (as in "hg init") all the forests, and then we'll be open for business. One of the many checks that Mercurial does when pushing (or pulling) changesets is to make sure that the source and target repositories are "related" by having the same initial changeset. If that condition doesn't hold then the push (or pull) operation is aborted. We'll rely upon this check to ensure that no changesets from these experimental repositories accidentally make their way into the real, live, open-for-business repositories. - Mark From amitksaha at netbeans.org Fri Nov 2 14:45:58 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Fri, 2 Nov 2007 20:15:58 +0530 Subject: [Announce]:Article: Open JDK extends Sun JDK Message-ID: <547db2260711020745j6b84bb53lbbdacf056f7eee5b@mail.gmail.com> Hello all! I have published an article titled "Open JDK extends Sun JDK" in "Linux for You" magazine which is an India based Linux/Open Source Magazine ( http://www.lfymag.com). The article looks at Open JDK - its background, licensing specifics, etc and winds up showing how you can get started with 'javac' shipped with Open JDK. I believe, this will be a great introduction to readers in the subcontinent. Since it is a print magazine, a copy is not available online. However, I am willing to share it, so please ping me if you want to have a look at it. BTW, thanks Mark Klomp for his inputs. 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 neojia at gmail.com Sat Nov 3 07:10:08 2007 From: neojia at gmail.com (Neo Jia) Date: Sat, 3 Nov 2007 00:10:08 -0700 Subject: EXPERIMENTAL open repositories live In-Reply-To: <4728EF5F.7030006@sun.com> References: <4728EF5F.7030006@sun.com> Message-ID: <5d649bdb0711030010n30e9d6a2t7db8566bf5505b35@mail.gmail.com> So cool. Just synced with hg 0.9.5 on FC7. Thanks, Neo On 10/31/07, Kelly O'Hair wrote: > > Experimental openjdk repositories! > > http://hg.openjdk.java.net > > -kto > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From amitksaha at netbeans.org Mon Nov 5 03:15:06 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Mon, 5 Nov 2007 08:45:06 +0530 Subject: Interview on "IcedTea" Message-ID: <547db2260711041915r59470807t9ba3d89e2c5e7403@mail.gmail.com> Hi all! As briefly mentioned in an earlier post, I am working on an article on "IcedTea" for an India based Linux/Open Source Magazine. Though, the FAQ answers most questions related to "IcedTea", it would be nice to have an interview with the "IcedTea" developers answering some of them in a "first person" fashion. So, I would like to request you to kindly chip in with your thoughts: * The main motivation behind IcedTea * What is the future agenda? * Are there plans to support other distributions as well? Any other things you would like to be covered. I really appreciate your time and comments. Thank you very much! Regards, Amit -- Amit Kumar Saha *NetBeans Community Docs Contribution Coordinator* me blogs@ http://amitksaha.blogspot.com URL:http://amitsaha.in.googlepages.com From kurt at intricatesoftware.com Mon Nov 5 13:53:19 2007 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 05 Nov 2007 08:53:19 -0500 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: <4728B3FD.2090004@kaffe.org> References: <20071030044031.90EBA313@callebaut.niobe.net> <47288EA5.1050704@kaffe.org> <4728A489.1080308@intricatesoftware.com> <4728B3FD.2090004@kaffe.org> Message-ID: <472F204F.3020902@intricatesoftware.com> Sorry for the delayed reply... Dalibor Topic wrote: > 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. Ahh ok I understand now. Either way works and is fine for the BSD port. Whatever you and the other existing Members/Groups decide is fine. > 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. Indeed. That would raise the barriers for new ports to be very high I would think. Regards, -Kurt From amitksaha at netbeans.org Mon Nov 5 15:05:54 2007 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Mon, 5 Nov 2007 20:35:54 +0530 Subject: How does IcedTea plugging work? In-Reply-To: <1194262869.3247.1.camel@nirvana.limasoftware.net> References: <547db2260710310818h6897b58br7102868a8db7d5c@mail.gmail.com> <18216.41957.444562.830463@zebedee.pink> <547db2260710311016x4a9a9379yc768586a988eb08e@mail.gmail.com> <1193869685.3187.10.camel@nirvana.limasoftware.net> <547db2260711041908p3c215373ye4f8984c7d7effb1@mail.gmail.com> <1194262869.3247.1.camel@nirvana.limasoftware.net> Message-ID: <547db2260711050705m4939dd72le3be1e5845bbd8cc@mail.gmail.com> On 11/5/07, Mario Torre wrote: > Il giorno lun, 05/11/2007 alle 08.38 +0530, Amit Kumar Saha ha scritto: > > You definitely want to interview Lillian Angel :) [1] > She will give you all the information and point you to other > developers :) Thanks for the pointer. Have mailed her, looking forward to hear from her! Regards, Amit > > Hope that helps, > Mario > > [1] Lillian Angel > -- > 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/ > -- Amit Kumar Saha *NetBeans Community Docs Contribution Coordinator* me blogs@ http://amitksaha.blogspot.com URL:http://amitsaha.in.googlepages.com From robilad at kaffe.org Mon Nov 5 16:58:20 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Mon, 05 Nov 2007 17:58:20 +0100 Subject: Preparation for a porters group proposal (Re: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)) In-Reply-To: <20071105160207.7D30731C@callebaut.niobe.net> References: <20071105160207.7D30731C@callebaut.niobe.net> Message-ID: <472F4BAC.8030806@kaffe.org> Mark Reinhold wrote: > I expect that the long-term goal of any more serious porting effort will > be to integrate into one of the mainline JDK code bases. At that point > its corresponding Project would be archived, and further work on the port > would happen in the mainline. That'd be perfect. > So who'd like to propose a Porters Group? Dalibor? It would be a pleasure. I'll work with Greg and Kurt on a proposal, and would be glad to serve as the group's initial moderator for the time being. Meanwhile, we'll need (at least) two more existing members to join me as initial Porters Group members .. so please reply to this post, if you are interested in being an initial member of the group, or send me an e-mail off-list. cheers, dalibor topic From mr at sun.com Mon Nov 5 16:02:07 2007 From: mr at sun.com (Mark Reinhold) Date: Mon, 05 Nov 2007 08:02:07 -0800 Subject: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform) In-Reply-To: kurt@intricatesoftware.com; Mon, 05 Nov 2007 08:53:19 EST; <472F204F.3020902@intricatesoftware.com> Message-ID: <20071105160207.7D30731C@callebaut.niobe.net> I'm now convinced that, contrary to my earlier musings, a Porters Group is a good idea. It can serve as a coordination point for all in-progress porting efforts as well as a way for people working on such ports to gain experience and eventually become Members of the OpenJDK Community. As Dalibor said, it probably makes the most sense for each porting effort to have its own Project so that, e.g., more advanced ports such as BSD can keep their work separate from newer, more experimental ports (VMS?). I expect that the long-term goal of any more serious porting effort will be to integrate into one of the mainline JDK code bases. At that point its corresponding Project would be archived, and further work on the port would happen in the mainline. So who'd like to propose a Porters Group? Dalibor? - Mark From springer at reservoir.com Mon Nov 5 18:53:03 2007 From: springer at reservoir.com (Jonathan Springer) Date: Mon, 05 Nov 2007 12:53:03 -0600 Subject: Preparation for a porters group proposal (Re: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)) In-Reply-To: <472F4BAC.8030806@kaffe.org> References: <20071105160207.7D30731C@callebaut.niobe.net> <472F4BAC.8030806@kaffe.org> Message-ID: <472F668F.80906@reservoir.com> Dalibor Topic wrote: > Mark Reinhold wrote: > >> I expect that the long-term goal of any more serious porting effort will >> be to integrate into one of the mainline JDK code bases. At that point >> its corresponding Project would be archived, and further work on the port >> would happen in the mainline. > > That'd be perfect. > >> So who'd like to propose a Porters Group? Dalibor? > > It would be a pleasure. > > I'll work with Greg and Kurt on a proposal, and would be glad to serve > as the group's initial moderator for the time being. > > Meanwhile, we'll need (at least) two more existing members to join me as > initial Porters Group members .. so please reply to this post, if you > are interested in being an initial member of the group, or send me an > e-mail off-list. I am interested. Thanks, -Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From landonf at threerings.net Mon Nov 5 19:21:04 2007 From: landonf at threerings.net (Landon Fuller) Date: Mon, 5 Nov 2007 11:21:04 -0800 Subject: Porting: Mac OS X Leopard Message-ID: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> Given the recent discussion of porting, it was suggested I send this along to the discuss@ list. I've long wondered what it would take to get the FreeBSD Java Port running on OS X, so this weekend I spent a couple days getting Java 1.6 running on my x86 Leopard machine. I can report partial success -- hotspot compiles, the jre mostly bootstraps, and Hello World runs. Anything complex appears to trigger stack alignment issues (Apple's i386 API requires a 16-byte aligned stack) landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java -version java version "1.6.0_03-p3" Java(TM) SE Runtime Environment (build 1.6.0_03-p3- landonf_04_nov_2007_00_06-b00) Java HotSpot(TM) Server VM (build 1.6.0_03-p3- landonf_04_nov_2007_01_30-b00, mixed mode) landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java Hello Hello World! Given this, it seems that getting the full JDK running on OS X (using X11, no Aqua) is fairly achievable. I've posted the code, description, etc, here: http://landonf.bikemonkey.org/code/macosx/FreeBSD_Java_16.20071105.html Cheers, -landonf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Peter.Kessler at Sun.COM Mon Nov 5 19:55:50 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 05 Nov 2007 11:55:50 -0800 Subject: Porting: Mac OS X Leopard In-Reply-To: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> References: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> Message-ID: <472F7546.7060102@Sun.COM> Landon Fuller wrote: > Given the recent discussion of porting, it was suggested I send this along to the discuss@ list. > > I've long wondered what it would take to get the FreeBSD Java Port running on OS X, so this weekend I spent a couple days getting Java 1.6 running on my x86 Leopard machine. I can report partial success -- hotspot compiles, the jre mostly bootstraps, and Hello World runs. Anything complex appears to trigger stack alignment issues (Apple's i386 API requires a 16-byte aligned stack) > > landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java -version > java version "1.6.0_03-p3" > Java(TM) SE Runtime Environment (build 1.6.0_03-p3-landonf_04_nov_2007_00_06-b00) > Java HotSpot(TM) Server VM (build 1.6.0_03-p3-landonf_04_nov_2007_01_30-b00, mixed mode) > > landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java Hello > Hello World! > > Given this, it seems that getting the full JDK running on OS X (using X11, no Aqua) is fairly achievable. I've posted the code, description, etc, here: > http://landonf.bikemonkey.org/code/macosx/FreeBSD_Java_16.20071105.html > > Cheers, > -landonf Great progress! I note, however that this is work you did on JDK 1.6 under the JRL, rather than on OpenJDK under the GPLv2. If you mean to contribute this back to the OpenJDK under the GPLv2, you'll need to fill out and send back a Sun Contributor Agreement. You can get that form at http://www.sun.com/software/opensource/sca.pdf and the instructions for sending it to us are at http://openjdk.java.net/contribute/ The FAQ for the contrubutor agreement is at http://www.sun.com/software/opensource/contributor_agreement.jsp Thanks for contributing. ... peter From landonf at threerings.net Mon Nov 5 20:06:01 2007 From: landonf at threerings.net (Landon Fuller) Date: Mon, 5 Nov 2007 12:06:01 -0800 Subject: Porting: Mac OS X Leopard In-Reply-To: <472F7546.7060102@Sun.COM> References: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> <472F7546.7060102@Sun.COM> Message-ID: <539369E8-DB84-4523-91B4-4406534CF7DD@threerings.net> On Nov 5, 2007, at 11:55, Peter B. Kessler wrote: > Landon Fuller wrote: > >> Given the recent discussion of porting, it was suggested I send >> this along to the discuss@ list. >> I've long wondered what it would take to get the FreeBSD Java Port >> running on OS X, so this weekend I spent a couple days getting >> Java 1.6 running on my x86 Leopard machine. I can report partial >> success -- hotspot compiles, the jre mostly bootstraps, and Hello >> World runs. Anything complex appears to trigger stack alignment >> issues (Apple's i386 API requires a 16-byte aligned stack) >> landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java - >> version >> java version "1.6.0_03-p3" >> Java(TM) SE Runtime Environment (build 1.6.0_03-p3- >> landonf_04_nov_2007_00_06-b00) >> Java HotSpot(TM) Server VM (build 1.6.0_03-p3- >> landonf_04_nov_2007_01_30-b00, mixed mode) >> landonf at max:javasrc_1_6_jrl/control/build/bsd-i586> ./bin/java Hello >> Hello World! >> Given this, it seems that getting the full JDK running on OS X >> (using X11, no Aqua) is fairly achievable. I've posted the code, >> description, etc, here: >> http://landonf.bikemonkey.org/code/macosx/ >> FreeBSD_Java_16.20071105.html >> Cheers, >> -landonf > > > Great progress! I note, however that this is work you did on > JDK 1.6 under the JRL, rather than on OpenJDK under the GPLv2. Cheers. Since the code is based on FreeBSD's porting work, the FreeBSD code would also need to be moved from the JRL to the GPLv2 (and integrated with OpenJDK). That's a bit larger in scope than this weekend proof of concept, but something I'd love to see happen. =) -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From volker.simonis at gmail.com Mon Nov 5 20:41:08 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Nov 2007 21:41:08 +0100 Subject: Preparation for a porters group proposal (Re: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)) In-Reply-To: <472F4BAC.8030806@kaffe.org> References: <20071105160207.7D30731C@callebaut.niobe.net> <472F4BAC.8030806@kaffe.org> Message-ID: On 11/5/07, Dalibor Topic wrote: > Mark Reinhold wrote: > > I expect that the long-term goal of any more serious porting effort will > > be to integrate into one of the mainline JDK code bases. At that point > > its corresponding Project would be archived, and further work on the port > > would happen in the mainline. > > That'd be perfect. > > > So who'd like to propose a Porters Group? Dalibor? > > It would be a pleasure. > > I'll work with Greg and Kurt on a proposal, and would be glad to serve > as the group's initial moderator for the time being. > > Meanwhile, we'll need (at least) two more existing members to join me as > initial Porters Group members .. so please reply to this post, if you > are interested in being an initial member of the group, or send me an > e-mail off-list. > I'm also interested, altough I'm not a current member of any group. Follwing some thoughts about the problems and challenges a porting group may be faced with: After reading the posts on this topic in this and the two related threads in the last days, I understood that Sun is not willing and doesn't has the ability to officialy support, test and maintain other ports. This is understandable. However, I also understood from the various posts that Sun is willing to encourage and at some point even integrate other ports into OpenJDK or as Mark Reinhold put it: "I expect that the long-term goal of any more serious porting effort will be to integrate into one of the mainline JDK code bases". This is very good news! The question now arises, how Sun can help other ports to become integral parts of the JDK and what does Sun expect from other ports to achieve this goal? More concrete, we are speaking here about three different things: a. platform ports (ports to an operating system not officialy supported by Sun) b. architectural ports (ports to a processor architecture not officialy supported by Sun) c. platform/architectural ports (a combination of a. and b.) For the VM part (i.e. the Hotspot), the conditions for potential porters are already quite promising. The Hotspot project is already nicely separeted into a shared part, that more or less depends only on Posix libraries and a C++ compiler and three platform/architecture dependant parts that are located int the 'os/', 'cpu/' and 'os_cpu/' subdirectories. So in a perfect world, a porting group would at most need to work in these three subdirectories for their respective port. In practice however, the things are a little more complicated, because the shared code implicitly makes some assumptions about things like byte order or stack growth direction that are inherently platform dependant. Moreover the shared code still contains artefacts like "#ifdef " or "#ifdef ". And finally, we have the includeDB database, that may require some platform dependant files even if these files are empty, just to make the project compilable. The big question now is, how responsive Sun will be in handling changes to the points mentioned in the previous paragraph to support ports? A real port will definitely need at least minor changes in shared code because of the problems mentioned before although these changes should get smaller with every new port if they are done carefully. I personally think it will be crucial to handle such changes and to handle them in a timely manner in order to support other ports for two reasons: first of all it will make the Sun suported platforms themselves more robust and second, it will keep other ports from forking away from the OpenJDK source tree. So far we just spoke about the VM part of the JDK. However the JDK library (i.e. the j2se subdirectory), although it doesn't contain that much architecture specific code like the VM, isn't much easiers to handle either. The problem here is that currently distinguishes only two different platforms (i.e. subdirectories), namely 'j2se/src/windows/ ' and 'j2se/src/solaris/'. There's a "linux/' subdirectory, but in fact, all the code for the Linux OS is in the 'solaris/' subdirectory and the differences between the two is only separeted by preprocessor macros. This will make ports to other Unix-like operating systems harder with every new port that will be integrated. So again here the question arises if Sun is willing to factore out the code in the "j2se/" subdirectory in the same way that it was done for the Hotspot. In my eyes, this is a crucial requirement it Sun is taking the goal of integrating other ports into OpenJDK serious. Finally, even pure Java code contains artefacts like: if System.getProperty("os.name").equals("Linux") .... Of course, such code has to be changed as well if other ports are supposed to work within OpenJDK. Concluding this post, one can say that open sourcing the JDK was certainly a huge effort. However, building a strong and active community around OpenJDK, will be not less work. The fact that a portng group is in the process of beeing created is certainly a step into the right direction but a lot of efforts, both from Sun and the community will be needed to make OpenJDK a success. Volker From robilad at kaffe.org Mon Nov 5 20:55:59 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Mon, 05 Nov 2007 21:55:59 +0100 Subject: Preparation for a porters group proposal (Re: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)) In-Reply-To: <472F668F.80906@reservoir.com> References: <20071105160207.7D30731C@callebaut.niobe.net> <472F4BAC.8030806@kaffe.org> <472F668F.80906@reservoir.com> Message-ID: <472F835F.1060600@kaffe.org> Jonathan Springer wrote: > > I am interested. Thanks, > Thanks for offering your help, Jonathan. In order to be an 'Initial Member' of a group you need to already have member status inside OpenJDK, i.e. be on one of the existing teams, according to the interim governance rules. I know that you're working on the mipsel-linux port, which is something I'd love to see in the porters group, but I have no idea if you are already officially a Member of OpenJDK yet. If you are not yet a Member, no worries, Mark Reinhold, David Herron and Tom Marble (thanks guys!) have kindly offered to be Initial Members of the Group, so that bootstrapping requirement for the proposal of the group is already fulfilled. I'd be happy though to assist you with a proposal for a mipsel-linux port as soon as the group is created (proposal + two weeks time for discussion + a vote by IGB), though, and that should get you initiated as a member. cheers, dalibor topic From landonf at threerings.net Mon Nov 5 21:55:27 2007 From: landonf at threerings.net (Landon Fuller) Date: Mon, 5 Nov 2007 13:55:27 -0800 Subject: Porting: Mac OS X Leopard In-Reply-To: <20071105210831.GA96588@misty.eyesbeyond.com> References: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> <472F7546.7060102@Sun.COM> <539369E8-DB84-4523-91B4-4406534CF7DD@threerings.net> <20071105210831.GA96588@misty.eyesbeyond.com> Message-ID: <5EB35440-916B-4319-BCFF-002ADFE1547A@threerings.net> On Nov 5, 2007, at 13:08, Greg Lewis wrote: >> Cheers. Since the code is based on FreeBSD's porting work, the >> FreeBSD code would also need to be moved from the JRL to the GPLv2 >> (and integrated with OpenJDK). >> >> That's a bit larger in scope than this weekend proof of concept, but >> something I'd love to see happen. =) > > There is already a port to OpenJDK and there is work under way to > get it > incorporated into OpenJDK. I hope to be able to provide more details > on what is going on there in the near future :). That sounds super, looking forward to the details -- It would be quite fun to work on OpenJDK Darwin (and BSD) support. Please let me know how/if I can help! -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From springer at reservoir.com Mon Nov 5 23:01:07 2007 From: springer at reservoir.com (Jonathan Springer) Date: Mon, 05 Nov 2007 17:01:07 -0600 Subject: Preparation for a porters group proposal (Re: Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)) In-Reply-To: <472F835F.1060600@kaffe.org> References: <20071105160207.7D30731C@callebaut.niobe.net> <472F4BAC.8030806@kaffe.org> <472F668F.80906@reservoir.com> <472F835F.1060600@kaffe.org> Message-ID: <472FA0B3.7010205@reservoir.com> Dalibor Topic wrote: > Jonathan Springer wrote: > >> I am interested. Thanks, > > Thanks for offering your help, Jonathan. > > In order to be an 'Initial Member' of a group you need to already have > member status inside OpenJDK, i.e. be on one of the existing teams, > according to the interim governance rules. > > I know that you're working on the mipsel-linux port, which is something > I'd love to see in the porters group, but I have no idea if you are > already officially a Member of OpenJDK yet. No, you're right. > If you are not yet a Member, no worries, Mark Reinhold, David Herron and > Tom Marble (thanks guys!) have kindly offered to be Initial Members of > the Group, so that bootstrapping requirement for the proposal of the > group is already fulfilled. Great, thanks. > I'd be happy though to assist you with a proposal for a mipsel-linux > port as soon as the group is created (proposal + two weeks time for > discussion + a vote by IGB), though, and that should get you initiated > as a member. Sounds good, I will revisit this then. -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From iris.clark at sun.com Tue Nov 6 06:16:54 2007 From: iris.clark at sun.com (iris.clark at sun.com) Date: Mon, 5 Nov 2007 22:16:54 -0800 (PST) Subject: Format for JDK 6/7 changeset comments? Message-ID: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Hi. As you know, the experimental OpenJDK repositories for JDK 7 are available [1]. In anticipation of getting the repositories live, we need to decide what our convention for changeset comments should be. The required format of the comments will be enforced whenever the changeset is pushed into the JDK 6/7 master or group repository forests. Other Projects may copy these conventions, adopt some other conventions, or have no conventions, depending upon their goals. In the old system, depending on the group integration tree, several formats were in use. Here's the common information: - name of the person making the change - bugid (a 7-digit number allocated by the Sun bug database) - complete synopsis of the bug - comma-separated list of reviewers of the change (typically either username or e-mail address) Optional information which appears in some trees includes: - information about existenace or feasibility of regression/unit tests - pointer to associated webrev - list of approvals - contributor acknowledgements Though we expect most changesets to contain updates for a single bug, our convention should easily accommodate changesets involving multiple bugs. Based on informal discussions, here's a potential format: The number of lines in the changeset is equal to the number of bugs. For each bug, there is a line of the following form: : [*] where - a 7-digit bugid allocated by the Sun bug database - the complete synposis for the bugid * - a comma separated list of reviewers of the change (repository userid) The name of the person submitting the change is the user who created the changeset. For example: 4853841: Nervous text demo displays wrong version [iris, duke] This covers the common information but is that sufficient? I think that the optional information regarding testing, webrev, and approvals should be contained in the bug, but what about contributor acknowledgements? Perhaps something along these lines is more suitable: For each bug there is a block of the following form: : Review: * Credit: * where , , - described above - arbitrary string of contributor acknowledgments The first two lines are required. The third is optional. The name of the person submitting the change is user who created the changeset. For example: 4853841: Nervous text demo displays wrong version Review: iris, duke Credit: mr - for extending the demo to accept arguments I favor the compactness of the first format; but the second is more extensible and gives us a simple means to recognise key contributions besides simple authorship or review. What do you think? Thanks, iris [1] http://hg.openjdk.java.net From David.Holmes at Sun.COM Tue Nov 6 06:34:51 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 06 Nov 2007 16:34:51 +1000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <47300B0B.7000908@sun.com> Hi Iris, In our current scheme using teamware we have two levels of "comments". First there is the sccs delta comment; then there is the putback comment. Different groups use different conventions for what information is used for each kind of comment. One of the things we do with Hotspot putback comments (and sometimes sccs comments) is include, if deemed necessary, technical information about the change. This is particularly pertinent as many of our bug synopses don't shed any light on the nature of the bug let alone the nature of the fix. So the putback comment might give an overview of the general nature of the fix, while the sccs comment might be more specific regarding how the fix impacted a given file. The CR # and synopsis is generally always included to give context/traceability. So one thing I would hope to see in these changeset comments is this technical description - assuming there isn't some other more suitable place for this commentary. Cheers, David Holmes iris.clark at sun.com said the following on 6/11/07 04:16 PM: > Hi. > > As you know, the experimental OpenJDK repositories for JDK 7 are > available [1]. In anticipation of getting the repositories live, we > need to decide what our convention for changeset comments should be. > The required format of the comments will be enforced whenever the > changeset is pushed into the JDK 6/7 master or group repository > forests. Other Projects may copy these conventions, adopt some other > conventions, or have no conventions, depending upon their goals. > > In the old system, depending on the group integration tree, several > formats were in use. Here's the common information: > > - name of the person making the change > - bugid (a 7-digit number allocated by the Sun bug database) > - complete synopsis of the bug > - comma-separated list of reviewers of the change (typically > either username or e-mail address) > > Optional information which appears in some trees includes: > > - information about existenace or feasibility of regression/unit > tests > - pointer to associated webrev > - list of approvals > - contributor acknowledgements > > Though we expect most changesets to contain updates for a single bug, > our convention should easily accommodate changesets involving multiple > bugs. Based on informal discussions, here's a potential format: > > The number of lines in the changeset is equal to the number of bugs. > For each bug, there is a line of the following form: > > : [*] > > where > > - a 7-digit bugid allocated by the Sun bug database > - the complete synposis for the bugid > * - a comma separated list of reviewers of the change > (repository userid) > > The name of the person submitting the change is the user who created > the changeset. > > For example: > > 4853841: Nervous text demo displays wrong version [iris, duke] > > This covers the common information but is that sufficient? I think > that the optional information regarding testing, webrev, and approvals > should be contained in the bug, but what about contributor > acknowledgements? Perhaps something along these lines is more > suitable: > > For each bug there is a block of the following form: > > : > Review: * > Credit: * > > where > > , , > - described above > > - arbitrary string of contributor acknowledgments > > The first two lines are required. The third is optional. The name > of the person submitting the change is user who created the > changeset. > > For example: > > 4853841: Nervous text demo displays wrong version > Review: iris, duke > Credit: mr - for extending the demo to accept arguments > > I favor the compactness of the first format; but the second is more > extensible and gives us a simple means to recognise key contributions > besides simple authorship or review. > > What do you think? > > Thanks, > iris > > [1] http://hg.openjdk.java.net > From Peter.Kessler at Sun.COM Tue Nov 6 06:46:07 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 05 Nov 2007 22:46:07 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <47300DAF.3000102@Sun.COM> One comment, inline. ... peter iris.clark at sun.com wrote: > Hi. > > As you know, the experimental OpenJDK repositories for JDK 7 are > available [1]. In anticipation of getting the repositories live, we > need to decide what our convention for changeset comments should be. > The required format of the comments will be enforced whenever the > changeset is pushed into the JDK 6/7 master or group repository > forests. Other Projects may copy these conventions, adopt some other > conventions, or have no conventions, depending upon their goals. > > In the old system, depending on the group integration tree, several > formats were in use. Here's the common information: > > - name of the person making the change > - bugid (a 7-digit number allocated by the Sun bug database) > - complete synopsis of the bug > - comma-separated list of reviewers of the change (typically > either username or e-mail address) > > Optional information which appears in some trees includes: > > - information about existenace or feasibility of regression/unit > tests > - pointer to associated webrev > - list of approvals > - contributor acknowledgements > > Though we expect most changesets to contain updates for a single bug, > our convention should easily accommodate changesets involving multiple > bugs. Based on informal discussions, here's a potential format: > > The number of lines in the changeset is equal to the number of bugs. > For each bug, there is a line of the following form: > > : [*] > > where > > - a 7-digit bugid allocated by the Sun bug database > - the complete synposis for the bugid > * - a comma separated list of reviewers of the change > (repository userid) > > The name of the person submitting the change is the user who created > the changeset. > > For example: > > 4853841: Nervous text demo displays wrong version [iris, duke] > > This covers the common information but is that sufficient? I think > that the optional information regarding testing, webrev, and approvals > should be contained in the bug, but what about contributor > acknowledgements? While I would ordinarily agree with you that the optional information should be in the bug report, until we provide write access to our bug database to all our Members, there won't be a convenient way for them to add those things. I think we are stuck with changeset comments for the time being. ... peter > Perhaps something along these lines is more > suitable: > > For each bug there is a block of the following form: > > : > Review: * > Credit: * > > where > > , , > - described above > > - arbitrary string of contributor acknowledgments > > The first two lines are required. The third is optional. The name > of the person submitting the change is user who created the > changeset. > > For example: > > 4853841: Nervous text demo displays wrong version > Review: iris, duke > Credit: mr - for extending the demo to accept arguments > > I favor the compactness of the first format; but the second is more > extensible and gives us a simple means to recognise key contributions > besides simple authorship or review. > > What do you think? > > Thanks, > iris > > [1] http://hg.openjdk.java.net > From Weijun.Wang at Sun.COM Tue Nov 6 07:08:13 2007 From: Weijun.Wang at Sun.COM (Weijun Max Wang) Date: Tue, 06 Nov 2007 15:08:13 +0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <473012DD.5040904@sun.com> > 4853841: Nervous text demo displays wrong version [iris, duke] Do we need a verb (optional) at the beginning? say, Backout 4853841: Nervous text demo displays wrong version [iris, duke] Max From Andreas.Sterbenz at Sun.COM Tue Nov 6 07:38:04 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Mon, 05 Nov 2007 23:38:04 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <473019DC.5050105@sun.com> iris.clark at sun.com wrote: > > For example: > > 4853841: Nervous text demo displays wrong version [iris, duke] > > This covers the common information but is that sufficient? I think I agree with your proposal (: ), but I believe that all supplemental information about the bug should not be placed in the changeset comments but in the bug database. That includes the names of the reviewers. It is important that all information about a bug is collected in one place, not two or three. That place needs to be the bug database. Andreas. From Andreas.Sterbenz at Sun.COM Tue Nov 6 07:41:21 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Mon, 05 Nov 2007 23:41:21 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47300DAF.3000102@Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <47300DAF.3000102@Sun.COM> Message-ID: <47301AA1.9090600@sun.com> Peter B. Kessler wrote: >> For example: >> >> 4853841: Nervous text demo displays wrong version [iris, duke] >> >> This covers the common information but is that sufficient? I think >> that the optional information regarding testing, webrev, and approvals >> should be contained in the bug, but what about contributor >> acknowledgements? > > While I would ordinarily agree with you that the optional information > should be in the bug report, until we provide write access to our bug > database to all our Members, there won't be a convenient way for them > to add those things. I think we are stuck with changeset comments for > the time being. Because we don't have a publicly writable bug database, I assume that the process for non-Sun committers will have to be that they ask a Sun person to update the bug for them anyway to fill in the evaluation. In other words, the committer will send the evaluation, along with any additional information, via email to a Sun employee who will then put it into the bug database. So I don't think we need to stick it into the changeset comment. Andreas. From neojia at gmail.com Tue Nov 6 08:32:08 2007 From: neojia at gmail.com (Neo Jia) Date: Tue, 6 Nov 2007 00:32:08 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <5d649bdb0711060032y7fc23ef0g5d8f298666f1bc92@mail.gmail.com> Probably, my following questions are not that related with the description of a changeset. How many status can a changeset have? "new", "pending" and "submitted"? Will there be a state for review? For example, in that state, the committer cannot make changes any more. And he/she has to use another changeset to re-work his/her changes. How many files could we edit by a changeset? No restrictions or something else? Just want to bring up some general rules to use the changeset. Thanks, Neo On 11/5/07, iris.clark at sun.com wrote: > Hi. > > As you know, the experimental OpenJDK repositories for JDK 7 are > available [1]. In anticipation of getting the repositories live, we > need to decide what our convention for changeset comments should be. > The required format of the comments will be enforced whenever the > changeset is pushed into the JDK 6/7 master or group repository > forests. Other Projects may copy these conventions, adopt some other > conventions, or have no conventions, depending upon their goals. > > In the old system, depending on the group integration tree, several > formats were in use. Here's the common information: > > - name of the person making the change > - bugid (a 7-digit number allocated by the Sun bug database) > - complete synopsis of the bug > - comma-separated list of reviewers of the change (typically > either username or e-mail address) > > Optional information which appears in some trees includes: > > - information about existenace or feasibility of regression/unit > tests > - pointer to associated webrev > - list of approvals > - contributor acknowledgements > > Though we expect most changesets to contain updates for a single bug, > our convention should easily accommodate changesets involving multiple > bugs. Based on informal discussions, here's a potential format: > > The number of lines in the changeset is equal to the number of bugs. > For each bug, there is a line of the following form: > > : [*] > > where > > - a 7-digit bugid allocated by the Sun bug database > - the complete synposis for the bugid > * - a comma separated list of reviewers of the change > (repository userid) > > The name of the person submitting the change is the user who created > the changeset. > > For example: > > 4853841: Nervous text demo displays wrong version [iris, duke] > > This covers the common information but is that sufficient? I think > that the optional information regarding testing, webrev, and approvals > should be contained in the bug, but what about contributor > acknowledgements? Perhaps something along these lines is more > suitable: > > For each bug there is a block of the following form: > > : > Review: * > Credit: * > > where > > , , > - described above > > - arbitrary string of contributor acknowledgments > > The first two lines are required. The third is optional. The name > of the person submitting the change is user who created the > changeset. > > For example: > > 4853841: Nervous text demo displays wrong version > Review: iris, duke > Credit: mr - for extending the demo to accept arguments > > I favor the compactness of the first format; but the second is more > extensible and gives us a simple means to recognise key contributions > besides simple authorship or review. > > What do you think? > > Thanks, > iris > > [1] http://hg.openjdk.java.net > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From matt.fowles at gmail.com Tue Nov 6 13:28:59 2007 From: matt.fowles at gmail.com (Matt Fowles) Date: Tue, 6 Nov 2007 09:28:59 -0400 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47300B0B.7000908@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <47300B0B.7000908@sun.com> Message-ID: All~ I agree with David that there needs to be a place to explain technical details of what changed and not just the motivation for why it changed. Matt On 11/6/07, David Holmes - Sun Microsystems wrote: > Hi Iris, > > In our current scheme using teamware we have two levels of "comments". > First there is the sccs delta comment; then there is the putback comment. > > Different groups use different conventions for what information is used > for each kind of comment. > > One of the things we do with Hotspot putback comments (and sometimes > sccs comments) is include, if deemed necessary, technical information > about the change. This is particularly pertinent as many of our bug > synopses don't shed any light on the nature of the bug let alone the > nature of the fix. So the putback comment might give an overview of the > general nature of the fix, while the sccs comment might be more specific > regarding how the fix impacted a given file. The CR # and synopsis is > generally always included to give context/traceability. > > So one thing I would hope to see in these changeset comments is this > technical description - assuming there isn't some other more suitable > place for this commentary. > > Cheers, > David Holmes > > iris.clark at sun.com said the following on 6/11/07 04:16 PM: > > Hi. > > > > As you know, the experimental OpenJDK repositories for JDK 7 are > > available [1]. In anticipation of getting the repositories live, we > > need to decide what our convention for changeset comments should be. > > The required format of the comments will be enforced whenever the > > changeset is pushed into the JDK 6/7 master or group repository > > forests. Other Projects may copy these conventions, adopt some other > > conventions, or have no conventions, depending upon their goals. > > > > In the old system, depending on the group integration tree, several > > formats were in use. Here's the common information: > > > > - name of the person making the change > > - bugid (a 7-digit number allocated by the Sun bug database) > > - complete synopsis of the bug > > - comma-separated list of reviewers of the change (typically > > either username or e-mail address) > > > > Optional information which appears in some trees includes: > > > > - information about existenace or feasibility of regression/unit > > tests > > - pointer to associated webrev > > - list of approvals > > - contributor acknowledgements > > > > Though we expect most changesets to contain updates for a single bug, > > our convention should easily accommodate changesets involving multiple > > bugs. Based on informal discussions, here's a potential format: > > > > The number of lines in the changeset is equal to the number of bugs. > > For each bug, there is a line of the following form: > > > > : [*] > > > > where > > > > - a 7-digit bugid allocated by the Sun bug database > > - the complete synposis for the bugid > > * - a comma separated list of reviewers of the change > > (repository userid) > > > > The name of the person submitting the change is the user who created > > the changeset. > > > > For example: > > > > 4853841: Nervous text demo displays wrong version [iris, duke] > > > > This covers the common information but is that sufficient? I think > > that the optional information regarding testing, webrev, and approvals > > should be contained in the bug, but what about contributor > > acknowledgements? Perhaps something along these lines is more > > suitable: > > > > For each bug there is a block of the following form: > > > > : > > Review: * > > Credit: * > > > > where > > > > , , > > - described above > > > > - arbitrary string of contributor acknowledgments > > > > The first two lines are required. The third is optional. The name > > of the person submitting the change is user who created the > > changeset. > > > > For example: > > > > 4853841: Nervous text demo displays wrong version > > Review: iris, duke > > Credit: mr - for extending the demo to accept arguments > > > > I favor the compactness of the first format; but the second is more > > extensible and gives us a simple means to recognise key contributions > > besides simple authorship or review. > > > > What do you think? > > > > Thanks, > > iris > > > > [1] http://hg.openjdk.java.net > > > From Kelly.Ohair at Sun.COM Tue Nov 6 17:03:01 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 06 Nov 2007 09:03:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <473019DC.5050105@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> Message-ID: <47309E45.3030106@sun.com> I agree. The more you put in the changeset comment, the higher the odds that there will be mistakes in those comments, mistakes that can NEVER be corrected. I favor keeping it short and sweet, and use the bug database for all other information. A place that can be corrected and added to over time. Of course the bug database needs to refer to the changeset, which IS the true source of the change. Any webrevs and diffs in the bug database should probably be removed once a changeset is public, or perhaps multiple changesets depending on how many it takes to really fix a bug. You don't want incorrect diffs or webrevs floating around when the true change is in the changeset. -kto Andreas Sterbenz wrote: > iris.clark at sun.com wrote: >> >> For example: >> >> 4853841: Nervous text demo displays wrong version [iris, duke] >> >> This covers the common information but is that sufficient? I think > > I agree with your proposal (: ), but I believe that all > supplemental information about the bug should not be placed in the > changeset comments but in the bug database. That includes the names of > the reviewers. It is important that all information about a bug is > collected in one place, not two or three. That place needs to be the bug > database. > > Andreas. > From Kelly.Ohair at Sun.COM Tue Nov 6 17:04:03 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 06 Nov 2007 09:04:03 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <47300B0B.7000908@sun.com> Message-ID: <47309E83.3000400@sun.com> And I think using the changeset comment for that is the wrong place to put it. -kto Matt Fowles wrote: > All~ > > I agree with David that there needs to be a place to explain technical > details of what changed and not just the motivation for why it > changed. > > Matt > > On 11/6/07, David Holmes - Sun Microsystems wrote: >> Hi Iris, >> >> In our current scheme using teamware we have two levels of "comments". >> First there is the sccs delta comment; then there is the putback comment. >> >> Different groups use different conventions for what information is used >> for each kind of comment. >> >> One of the things we do with Hotspot putback comments (and sometimes >> sccs comments) is include, if deemed necessary, technical information >> about the change. This is particularly pertinent as many of our bug >> synopses don't shed any light on the nature of the bug let alone the >> nature of the fix. So the putback comment might give an overview of the >> general nature of the fix, while the sccs comment might be more specific >> regarding how the fix impacted a given file. The CR # and synopsis is >> generally always included to give context/traceability. >> >> So one thing I would hope to see in these changeset comments is this >> technical description - assuming there isn't some other more suitable >> place for this commentary. >> >> Cheers, >> David Holmes >> >> iris.clark at sun.com said the following on 6/11/07 04:16 PM: >>> Hi. >>> >>> As you know, the experimental OpenJDK repositories for JDK 7 are >>> available [1]. In anticipation of getting the repositories live, we >>> need to decide what our convention for changeset comments should be. >>> The required format of the comments will be enforced whenever the >>> changeset is pushed into the JDK 6/7 master or group repository >>> forests. Other Projects may copy these conventions, adopt some other >>> conventions, or have no conventions, depending upon their goals. >>> >>> In the old system, depending on the group integration tree, several >>> formats were in use. Here's the common information: >>> >>> - name of the person making the change >>> - bugid (a 7-digit number allocated by the Sun bug database) >>> - complete synopsis of the bug >>> - comma-separated list of reviewers of the change (typically >>> either username or e-mail address) >>> >>> Optional information which appears in some trees includes: >>> >>> - information about existenace or feasibility of regression/unit >>> tests >>> - pointer to associated webrev >>> - list of approvals >>> - contributor acknowledgements >>> >>> Though we expect most changesets to contain updates for a single bug, >>> our convention should easily accommodate changesets involving multiple >>> bugs. Based on informal discussions, here's a potential format: >>> >>> The number of lines in the changeset is equal to the number of bugs. >>> For each bug, there is a line of the following form: >>> >>> : [*] >>> >>> where >>> >>> - a 7-digit bugid allocated by the Sun bug database >>> - the complete synposis for the bugid >>> * - a comma separated list of reviewers of the change >>> (repository userid) >>> >>> The name of the person submitting the change is the user who created >>> the changeset. >>> >>> For example: >>> >>> 4853841: Nervous text demo displays wrong version [iris, duke] >>> >>> This covers the common information but is that sufficient? I think >>> that the optional information regarding testing, webrev, and approvals >>> should be contained in the bug, but what about contributor >>> acknowledgements? Perhaps something along these lines is more >>> suitable: >>> >>> For each bug there is a block of the following form: >>> >>> : >>> Review: * >>> Credit: * >>> >>> where >>> >>> , , >>> - described above >>> >>> - arbitrary string of contributor acknowledgments >>> >>> The first two lines are required. The third is optional. The name >>> of the person submitting the change is user who created the >>> changeset. >>> >>> For example: >>> >>> 4853841: Nervous text demo displays wrong version >>> Review: iris, duke >>> Credit: mr - for extending the demo to accept arguments >>> >>> I favor the compactness of the first format; but the second is more >>> extensible and gives us a simple means to recognise key contributions >>> besides simple authorship or review. >>> >>> What do you think? >>> >>> Thanks, >>> iris >>> >>> [1] http://hg.openjdk.java.net >>> From aph at redhat.com Tue Nov 6 17:23:04 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Nov 2007 17:23:04 +0000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47309E45.3030106@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> Message-ID: <18224.41720.904658.948565@zebedee.pink> Kelly O'Hair writes: > I agree. > > The more you put in the changeset comment, the higher the odds that > there will be mistakes in those comments, mistakes that can NEVER > be corrected. > I favor keeping it short and sweet, and use the bug database for > all other information. A place that can be corrected and added to > over time. > > Of course the bug database needs to refer to the changeset, which > IS the true source of the change. Any webrevs and diffs in the bug > database should probably be removed once a changeset is public, or > perhaps multiple changesets depending on how many it takes to > really fix a bug. You don't want incorrect diffs or webrevs > floating around when the true change is in the changeset. Hmm. Does this mean that the checkin comments are not written until after the reviewer has done their work? That seems wrong. In gcc we write the change log entry when we submit a change. Also, IMO the supplemental information about the bug should be automatically copied into a mailing list as part of the same thread to which the change itself was copied. That way, you only need mailing list searching software to find everything. It would be better not to depend on the bug database in order to find out why something has changed, or indeed what has changed. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From neal.gafter at gmail.com Tue Nov 6 17:29:47 2007 From: neal.gafter at gmail.com (Neal Gafter) Date: Tue, 6 Nov 2007 09:29:47 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47309E45.3030106@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> Message-ID: <15e8b9d20711060929n26ee544do9265c17599f85837@mail.gmail.com> On Nov 6, 2007 9:03 AM, Kelly O'Hair wrote: > I favor keeping it short and sweet, and use the bug database for all other > information. > A place that can be corrected and added to over time. > Agreed. This assumes the bug database is open for writing by committers and reading by the larger community. Sun is in a position to control the bug database to hide bugs that describe security problems. That is fine and I expect it to continue, but I have seen a number of cases of bugs being hidden because the problems they describe are embarrasing. Unfortunately (1) such problems then don't get fixed, and (2) even if it is too late to fix the issues, by sweeping them under the rug we don't learn from past mistakes. My point is that in order for committers to have confidence in this approach, Sun should give up some of their editorial/censorship role over the bug database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitri.Trembovetski at Sun.COM Tue Nov 6 17:34:18 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 06 Nov 2007 09:34:18 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47309E83.3000400@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <47300B0B.7000908@sun.com> <47309E83.3000400@sun.com> Message-ID: <4730A59A.1000706@Sun.COM> Kelly O'Hair wrote: > And I think using the changeset comment for that is the wrong place to > put it. I agree with Kelly here. This kind of information should be in the bug evaluation. >>> about the change. This is particularly pertinent as many of our bug >>> synopses don't shed any light on the nature of the bug let alone the >>> nature of the fix. Then why not the synopsis of the bug? We do this all the time. Thanks, Dmitri > > -kto > > Matt Fowles wrote: >> All~ >> >> I agree with David that there needs to be a place to explain technical >> details of what changed and not just the motivation for why it >> changed. >> >> Matt >> >> On 11/6/07, David Holmes - Sun Microsystems wrote: >>> Hi Iris, >>> >>> In our current scheme using teamware we have two levels of "comments". >>> First there is the sccs delta comment; then there is the putback >>> comment. >>> >>> Different groups use different conventions for what information is used >>> for each kind of comment. >>> >>> One of the things we do with Hotspot putback comments (and sometimes >>> sccs comments) is include, if deemed necessary, technical information >>> about the change. This is particularly pertinent as many of our bug >>> synopses don't shed any light on the nature of the bug let alone the >>> nature of the fix. So the putback comment might give an overview of the >>> general nature of the fix, while the sccs comment might be more specific >>> regarding how the fix impacted a given file. The CR # and synopsis is >>> generally always included to give context/traceability. >>> >>> So one thing I would hope to see in these changeset comments is this >>> technical description - assuming there isn't some other more suitable >>> place for this commentary. >>> >>> Cheers, >>> David Holmes >>> >>> iris.clark at sun.com said the following on 6/11/07 04:16 PM: >>>> Hi. >>>> >>>> As you know, the experimental OpenJDK repositories for JDK 7 are >>>> available [1]. In anticipation of getting the repositories live, we >>>> need to decide what our convention for changeset comments should be. >>>> The required format of the comments will be enforced whenever the >>>> changeset is pushed into the JDK 6/7 master or group repository >>>> forests. Other Projects may copy these conventions, adopt some other >>>> conventions, or have no conventions, depending upon their goals. >>>> >>>> In the old system, depending on the group integration tree, several >>>> formats were in use. Here's the common information: >>>> >>>> - name of the person making the change >>>> - bugid (a 7-digit number allocated by the Sun bug database) >>>> - complete synopsis of the bug >>>> - comma-separated list of reviewers of the change (typically >>>> either username or e-mail address) >>>> >>>> Optional information which appears in some trees includes: >>>> >>>> - information about existenace or feasibility of regression/unit >>>> tests >>>> - pointer to associated webrev >>>> - list of approvals >>>> - contributor acknowledgements >>>> >>>> Though we expect most changesets to contain updates for a single bug, >>>> our convention should easily accommodate changesets involving multiple >>>> bugs. Based on informal discussions, here's a potential format: >>>> >>>> The number of lines in the changeset is equal to the number of bugs. >>>> For each bug, there is a line of the following form: >>>> >>>> : [*] >>>> >>>> where >>>> >>>> - a 7-digit bugid allocated by the Sun bug database >>>> - the complete synposis for the bugid >>>> * - a comma separated list of reviewers of the change >>>> (repository userid) >>>> >>>> The name of the person submitting the change is the user who created >>>> the changeset. >>>> >>>> For example: >>>> >>>> 4853841: Nervous text demo displays wrong version [iris, duke] >>>> >>>> This covers the common information but is that sufficient? I think >>>> that the optional information regarding testing, webrev, and approvals >>>> should be contained in the bug, but what about contributor >>>> acknowledgements? Perhaps something along these lines is more >>>> suitable: >>>> >>>> For each bug there is a block of the following form: >>>> >>>> : >>>> Review: * >>>> Credit: * >>>> >>>> where >>>> >>>> , , >>>> - described above >>>> >>>> - arbitrary string of contributor acknowledgments >>>> >>>> The first two lines are required. The third is optional. The name >>>> of the person submitting the change is user who created the >>>> changeset. >>>> >>>> For example: >>>> >>>> 4853841: Nervous text demo displays wrong version >>>> Review: iris, duke >>>> Credit: mr - for extending the demo to accept arguments >>>> >>>> I favor the compactness of the first format; but the second is more >>>> extensible and gives us a simple means to recognise key contributions >>>> besides simple authorship or review. >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> iris >>>> >>>> [1] http://hg.openjdk.java.net >>>> From Kelly.Ohair at Sun.COM Tue Nov 6 18:22:39 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 06 Nov 2007 10:22:39 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <15e8b9d20711060929n26ee544do9265c17599f85837@mail.gmail.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> <15e8b9d20711060929n26ee544do9265c17599f85837@mail.gmail.com> Message-ID: <4730B0EF.50106@sun.com> I agree that we need a completely open bug database, and I do think that will happen. For the time being I have been trying to get people to use the more open parts of the existing bug database, parts that are at least visible to the outside world (Description/Evaluation etc.). But let's not make a decision on the changeset comment based on the existing bug database situation, one that will be changing in the future. At least that's my thinking. -kto Neal Gafter wrote: > On Nov 6, 2007 9:03 AM, Kelly O'Hair > wrote: > > I favor keeping it short and sweet, and use the bug database for all > other information. > A place that can be corrected and added to over time. > > > Agreed. This assumes the bug database is open for writing by committers > and reading by the larger community. > > Sun is in a position to control the bug database to hide bugs that > describe security problems. That is fine and I expect it to continue, > but I have seen a number of cases of bugs being hidden because the > problems they describe are embarrasing. Unfortunately (1) such problems > then don't get fixed, and (2) even if it is too late to fix the issues, > by sweeping them under the rug we don't learn from past mistakes. > > My point is that in order for committers to have confidence in this > approach, Sun should give up some of their editorial/censorship role > over the bug database. From Kelly.Ohair at Sun.COM Tue Nov 6 18:28:36 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 06 Nov 2007 10:28:36 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <18224.41720.904658.948565@zebedee.pink> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> <18224.41720.904658.948565@zebedee.pink> Message-ID: <4730B254.8040907@sun.com> Mercurial changesets should not be created until the change has been reviewed and is ready to be integrated into a public area. Changes that are untested, unreviewed, or experimental should stay as patches, at least that's my opinion after using Mercurial for some time. If we allow completely unreviewed and untested changesets into the repositories, we run the risk of severe changeset clutter. They don't have to be perfect, but we need some kind of quality control on them. People need to try the mq extension (myself included), which may provide some answers here. And the notifications of changesets that have been integrated can include the diffs, but when you can easily and quickly browse the changeset, I'm not so sure you need to send all the diffs. But that's a changeset notification issue, not a changeset comment format issue. -kto Andrew Haley wrote: > Kelly O'Hair writes: > > I agree. > > > > The more you put in the changeset comment, the higher the odds that > > there will be mistakes in those comments, mistakes that can NEVER > > be corrected. > > I favor keeping it short and sweet, and use the bug database for > > all other information. A place that can be corrected and added to > > over time. > > > > Of course the bug database needs to refer to the changeset, which > > IS the true source of the change. Any webrevs and diffs in the bug > > database should probably be removed once a changeset is public, or > > perhaps multiple changesets depending on how many it takes to > > really fix a bug. You don't want incorrect diffs or webrevs > > floating around when the true change is in the changeset. > > Hmm. Does this mean that the checkin comments are not written until > after the reviewer has done their work? That seems wrong. In gcc we > write the change log entry when we submit a change. > > Also, IMO the supplemental information about the bug should be > automatically copied into a mailing list as part of the same thread to > which the change itself was copied. That way, you only need mailing > list searching software to find everything. It would be better not to > depend on the bug database in order to find out why something has > changed, or indeed what has changed. > > Andrew. > From mr at sun.com Tue Nov 6 20:36:33 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 06 Nov 2007 12:36:33 -0800 Subject: Upcoming OpenJDK infrastructure projects Message-ID: <20071106203633.27F1766B3@eggemoggin.niobe.net> http://blogs.sun.com/mr/entry/under_construction Comments welcome! - Mark From Bradford.Wetmore at Sun.COM Wed Nov 7 02:48:04 2007 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Tue, 06 Nov 2007 18:48:04 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <5d649bdb0711060032y7fc23ef0g5d8f298666f1bc92@mail.gmail.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <5d649bdb0711060032y7fc23ef0g5d8f298666f1bc92@mail.gmail.com> Message-ID: <47312764.6080302@sun.com> > How many status can a changeset have? "new", "pending" and > "submitted"? Will there be a state for review? I haven't seen any response to your questions yet, so let me take a quick stab at the current architecture of our bug database. (Each group handles their bug states a little differently, so what I may describe may be met with guffaws from other groups. There is a "How-To" document under development that will layout more specifics, so this is a quick overview that may change with time.) Please see Kelly's "Mercurial Wheel" blog entry if you haven't already: http://blogs.sun.com/kto/entry/openjdk_mercurial_wheel Be sure to note the part about being nice to your integrator... ;) Dispatched No one's looked at it. Incomplete Someone's looked at it, need more info, there's missing info, etc. Accepted Someone's looked at it, agrees it should be tracked. Cause not known yet. Defer Can't do anything about it now. Cause known Understand the problem, but not the fix. Fix Understood Understand problem, have a good idea for solution. Fix In Progress Actively working on fix. Fix Available Fix is ready and has been delivered, but is not in MASTER yet. Fix Failed Rats! Back to drawing board. Fix Delivered Fix is in the MASTER. Closed Fix in the MASTER has been verified. So, to your questions. You can probably now map each bug state to the stage you're working on. When you start coding, you're in Fix in Progress (FIP). When you've submitted code for review, you're still FIP. Once you're approved, create your changeset, and putback to your gate. At that point, you mark the bug as "Fix Available". Kelly wrote: > Mercurial changesets should not be created until the change has been > reviewed and is ready to be integrated into a public area. > Changes that are untested, unreviewed, or experimental should stay as > patches, at least that's my opinion after using Mercurial for some > time. +1 At some interval, your friendly neighborhood gatekeeper (possibly me) will loving collect your changes along with the others received to date, build and run the available tests, then gently place your changes into the MASTER workspace and move the bug into the "Fix Delivered" state. Most gatekeepers will accept changes as long as they are accompanied by good quality chocolate. Watch out for gatekeepers that have more...ummm...refined tastes (fine wine, ports). I'd stay away from Duke, he'll make you attend JavaOne. Feel free to ignore the entire previous paragraph. I do like chocolate tho... ;-) Anyone Europeans out there? Neo wrote: > For example, in that > state, the committer cannot make changes any more. And he/she has to > use another changeset to re-work his/her changes. Once your fix is delivered (goes into Fix available state), you will probably need to do another change set as anyone can now download it. > How many files could we edit by a changeset? No restrictions or something else? I don't know of any restrictions on numbers. If you're thinking of changing thousands of files, we will want to know about it. ;) Brad Java Security/Network Integrator From mr at sun.com Wed Nov 7 03:12:01 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 06 Nov 2007 19:12:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: dmitri.trembovetski@sun.com; Tue, 06 Nov 2007 09:34:18 PST; <4730A59A.1000706@Sun.COM> Message-ID: <20071107031201.D0C4A312@callebaut.niobe.net> > Date: Tue, 06 Nov 2007 09:34:18 -0800 > From: dmitri.trembovetski at sun.com > Kelly O'Hair wrote: >> And I think using the changeset comment for that is the wrong place to >> put it. > > I agree with Kelly here. This kind of information should be in the > bug evaluation. Absolutely. > >>> about the change. This is particularly pertinent as many of our bug > >>> synopses don't shed any light on the nature of the bug let alone the > >>> nature of the fix. > > Then why not the synopsis of the bug? We do this all the time. I think you meant to write "why not _edit_ the synopsis of the bug?", and I completely agree. I do that all the time, and I regularly encourage others to do so. There's no good reason to retain a bad synopsis. - Mark From mr at sun.com Wed Nov 7 03:17:15 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 06 Nov 2007 19:17:15 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: neal.gafter@gmail.com; Tue, 06 Nov 2007 09:29:47 PST; <15e8b9d20711060929n26ee544do9265c17599f85837@mail.gmail.com> Message-ID: <20071107031715.87431312@callebaut.niobe.net> > Date: Tue, 06 Nov 2007 09:29:47 -0800 > From: neal.gafter at gmail.com > ... > > Sun is in a position to control the bug database to hide bugs that describe > security problems. That is fine and I expect it to continue, but I have seen > a number of cases of bugs being hidden because the problems they describe > are embarrasing. Unfortunately (1) such problems then don't get fixed, and > (2) even if it is too late to fix the issues, by sweeping them under the rug > we don't learn from past mistakes. I'd be happy to hear about specific cases of this scenario, so that they can be addressed. - Mark From dan at fabulich.com Wed Nov 7 05:32:30 2007 From: dan at fabulich.com (Dan Fabulich) Date: Tue, 6 Nov 2007 21:32:30 -0800 (Pacific Standard Time) Subject: Upcoming OpenJDK infrastructure projects In-Reply-To: <20071106203633.27F1766B3@eggemoggin.niobe.net> References: <20071106203633.27F1766B3@eggemoggin.niobe.net> Message-ID: I'm not sure if this request is in-scope for "OpenJDK infrastructure projects", but I'd like to pipe up in favor of simplifying the Windows build experience. Specifically... 1) Update the build to work with Visual C++ 2005 Express, the free (no-charge) version of the Visual Studio C++ compiler. The fix isn't too hard, but it requires a bit of figuring: http://bugs.sun.com/view_bug.do?bug_id=6523947 2) Provide support for building under MSYS make/shell, perhaps instead of Cygwin. Cygwin make doesn't handle paths of the form "c:/code/openjdk" and has stated that they intend not to; they recommend using the MinGW MSYS make instead of Cygwin make for these purposes. http://cygwin.com/ml/cygwin/2006-07/msg00671.html The Mozilla project updated their Cygwin-only build to work under MSYS, and now offer a convenient installer to set the whole thing up. Something like that for OpenJDK would be fantastic, though it's just a dream at this point. :-) http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites (Note that I DON'T mean that we should support building with MinGW gcc; that'd be cool, but IMO it's not necessary to build Windows software using a Free-as-in-speech compiler; using a free-as-in-beer compiler is fine for non-free platforms.) I'd hoped to begin work on these myself at some point, though I'm pretty busy yet. :-( -Dan From David.Holmes at Sun.COM Wed Nov 7 05:51:56 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Nov 2007 15:51:56 +1000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071107031201.D0C4A312@callebaut.niobe.net> References: <20071107031201.D0C4A312@callebaut.niobe.net> Message-ID: <4731527C.6070800@sun.com> Mark, Mark Reinhold said the following on 7/11/07 01:12 PM: > >> >>> about the change. This is particularly pertinent as many of our bug >> >>> synopses don't shed any light on the nature of the bug let alone the >> >>> nature of the fix. >> >> Then why not the synopsis of the bug? We do this all the time. > > I think you meant to write "why not _edit_ the synopsis of the bug?", and > I completely agree. I do that all the time, and I regularly encourage > others to do so. There's no good reason to retain a bad synopsis. Very often the synopsis reflects the circumstances under which the user encountered the bug eg: test regression/java/lang/Foo throws IllegalArgumentException or Foo applet crashes after Java 6 update or SIGSEGV running xxxx with option yyyy Are you suggesting that once the cause of a bug is determined then the synopsis should be changed to reflect that? I've updated a few "bad" synopses in my time too, but not generally to the extent of changing them from being failure oriented to being cause oriented. Cheers, David Holmes From aph at redhat.com Wed Nov 7 11:47:35 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Nov 2007 11:47:35 +0000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <4730B254.8040907@sun.com> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> <18224.41720.904658.948565@zebedee.pink> <4730B254.8040907@sun.com> Message-ID: <18225.42455.104750.342011@zebedee.pink> Kelly O'Hair writes: > Mercurial changesets should not be created until the change has > been reviewed and is ready to be integrated into a public area. > Changes that are untested, unreviewed, or experimental should stay > as patches, at least that's my opinion after using Mercurial for > some time. > If we allow completely unreviewed and untested changesets into the > repositories, we run the risk of severe changeset clutter. They > don't have to be perfect, but we need some kind of quality control > on them. Sure, but that seems to be orthogonal to what I wrote. I am trying to make sure that all the information about every change is in a searchable form that doesn't require special software. I'm trying to make sure that if (God forbid) a nuke fell on Sun central, everyone else would just carry on with their work, with all of the information they need easily to have. I'll explain what we do at GNU, and why I think it's a good thing. The comment we write for a change is written and submitted for review along with the patch. When the patch is approved, this pre-written comment is used for the version control commit. So, when you look at a patch submission you can immediately tie it with the commit. > People need to try the mq extension (myself included), which may > provide some answers here. > > And the notifications of changesets that have been integrated can > include the diffs, but when you can easily and quickly browse the > changeset, I'm not so sure you need to send all the diffs. Agreed, but that's a matter of making sure that the changeset, once checked in, really was exactly the same as what was reviewed. Redundancy here is a good thing. > But that's a changeset notification issue, not a changeset comment > format issue. True enough. Andrew. > Andrew Haley wrote: > > Kelly O'Hair writes: > > > I agree. > > > > > > The more you put in the changeset comment, the higher the odds that > > > there will be mistakes in those comments, mistakes that can NEVER > > > be corrected. > > > I favor keeping it short and sweet, and use the bug database for > > > all other information. A place that can be corrected and added to > > > over time. > > > > > > Of course the bug database needs to refer to the changeset, which > > > IS the true source of the change. Any webrevs and diffs in the bug > > > database should probably be removed once a changeset is public, or > > > perhaps multiple changesets depending on how many it takes to > > > really fix a bug. You don't want incorrect diffs or webrevs > > > floating around when the true change is in the changeset. > > > > Hmm. Does this mean that the checkin comments are not written until > > after the reviewer has done their work? That seems wrong. In gcc we > > write the change log entry when we submit a change. > > > > Also, IMO the supplemental information about the bug should be > > automatically copied into a mailing list as part of the same thread to > > which the change itself was copied. That way, you only need mailing > > list searching software to find everything. It would be better not to > > depend on the bug database in order to find out why something has > > changed, or indeed what has changed. > > > > Andrew. > > -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Kelly.Ohair at Sun.COM Wed Nov 7 17:04:58 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 07 Nov 2007 09:04:58 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <18225.42455.104750.342011@zebedee.pink> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> <473019DC.5050105@sun.com> <47309E45.3030106@sun.com> <18224.41720.904658.948565@zebedee.pink> <4730B254.8040907@sun.com> <18225.42455.104750.342011@zebedee.pink> Message-ID: <4731F03A.50608@sun.com> Andrew Haley wrote: > Kelly O'Hair writes: > > > Mercurial changesets should not be created until the change has > > been reviewed and is ready to be integrated into a public area. > > > Changes that are untested, unreviewed, or experimental should stay > > as patches, at least that's my opinion after using Mercurial for > > some time. > > > If we allow completely unreviewed and untested changesets into the > > repositories, we run the risk of severe changeset clutter. They > > don't have to be perfect, but we need some kind of quality control > > on them. > > Sure, but that seems to be orthogonal to what I wrote. > > I am trying to make sure that all the information about every change > is in a searchable form that doesn't require special software. I'm > trying to make sure that if (God forbid) a nuke fell on Sun central, > everyone else would just carry on with their work, with all of the > information they need easily to have. I'm not directly involved in the bug tracking system plans, but I'd be very surprised if the system we pick isn't searchable, it certainly will be open. I know that until we have a completely open bug tracking system, this could be an issue, but I really hate to design around the current status when we know it will be changing. > > I'll explain what we do at GNU, and why I think it's a good thing. > > The comment we write for a change is written and submitted for review > along with the patch. When the patch is approved, this pre-written > comment is used for the version control commit. So, when you look at > a patch submission you can immediately tie it with the commit. The problem is that with code, you have reviewers looking at it, compilers compiling it, various tools looking for problems with it, tests running it, etc. But comments, as valuable as they are, are just words, and if they are wrong, the odds are very high that it won't be detected. The longer the comment, the better the odds of it having mistakes. And once baked in, those incorrect words live on forever. I'm not against comments by any means, but it just seems like putting them somewhere closer to the actual bug report, in a system that allows you to correct and expand upon later makes the most sense to me. And there is also the "one source of the truth" concept too. I'd like to know that the changeset is the one source of the code changes, and the bug report is the one source of what the bug is. > > > People need to try the mq extension (myself included), which may > > provide some answers here. > > > > And the notifications of changesets that have been integrated can > > include the diffs, but when you can easily and quickly browse the > > changeset, I'm not so sure you need to send all the diffs. > > Agreed, but that's a matter of making sure that the changeset, once > checked in, really was exactly the same as what was reviewed. > Redundancy here is a good thing. Redundancy is good when it helps find errors, so in terms of getting a change more exposure during a review or the initial push, sure this might allow for someone to catch a problem. I guess I was thinking more along the lines of archeology, I tend to not trust email diffs. -kto > > > But that's a changeset notification issue, not a changeset comment > > format issue. > > True enough. > > Andrew. > > > > Andrew Haley wrote: > > > Kelly O'Hair writes: > > > > I agree. > > > > > > > > The more you put in the changeset comment, the higher the odds that > > > > there will be mistakes in those comments, mistakes that can NEVER > > > > be corrected. > > > > I favor keeping it short and sweet, and use the bug database for > > > > all other information. A place that can be corrected and added to > > > > over time. > > > > > > > > Of course the bug database needs to refer to the changeset, which > > > > IS the true source of the change. Any webrevs and diffs in the bug > > > > database should probably be removed once a changeset is public, or > > > > perhaps multiple changesets depending on how many it takes to > > > > really fix a bug. You don't want incorrect diffs or webrevs > > > > floating around when the true change is in the changeset. > > > > > > Hmm. Does this mean that the checkin comments are not written until > > > after the reviewer has done their work? That seems wrong. In gcc we > > > write the change log entry when we submit a change. > > > > > > Also, IMO the supplemental information about the bug should be > > > automatically copied into a mailing list as part of the same thread to > > > which the change itself was copied. That way, you only need mailing > > > list searching software to find everything. It would be better not to > > > depend on the bug database in order to find out why something has > > > changed, or indeed what has changed. > > > > > > Andrew. > > > > From mr at sun.com Thu Nov 8 17:15:01 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 09:15:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: david.holmes@sun.com; Wed, 07 Nov 2007 15:51:56 +1000; <4731527C.6070800@sun.com> Message-ID: <20071108171501.11F8B78086@eggemoggin.niobe.net> > Date: Wed, 07 Nov 2007 15:51:56 +1000 > From: david.holmes at sun.com > ... > > Are you suggesting that once the cause of a bug is determined then the > synopsis should be changed to reflect that? I've updated a few "bad" > synopses in my time too, but not generally to the extent of changing > them from being failure oriented to being cause oriented. It's a judgement call. In most cases I agree that a bug's synopsis should reflect the symptom rather than the underlying cause. In some cases, however, the cause turns out to be something that can trigger a wide variety of different symptoms, so it makes more sense to change the synopsis to describe the cause, or a common aspect of all the known symptoms. My enthusiasm for rewriting synopses is more a reaction to the practice of some engineers of slavishly preserving the exact text of a bug's original synopsis, regardless of how poorly written it may be. That does nothing but slowly degrade the overall utility of the bug database. - Mark From mr at sun.com Thu Nov 8 17:46:00 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 09:46:00 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: aph@redhat.com; Wed, 07 Nov 2007 11:47:35 GMT; <18225.42455.104750.342011@zebedee.pink> Message-ID: <20071108174600.9E65B78086@eggemoggin.niobe.net> > Date: Wed, 07 Nov 2007 11:47:35 +0000 > From: Andrew Haley > ... > > I am trying to make sure that all the information about every change > is in a searchable form that doesn't require special software. I'm > trying to make sure that if (God forbid) a nuke fell on Sun central, > everyone else would just carry on with their work, with all of the > information they need easily to have. In general I think this is a good principle. > I'll explain what we do at GNU, and why I think it's a good thing. > > The comment we write for a change is written and submitted for review > along with the patch. When the patch is approved, this pre-written > comment is used for the version control commit. So, when you look at > a patch submission you can immediately tie it with the commit. So does the comment describing the technical nature of the change ever wind up anywhere else -- e.g., in a Bugzilla entry? The usual practice at Sun has been to put that kind of information into the evaluation section of the bug report. Some teams have also put that information, or a variant of it, into TeamWare delta or putback comments. That's always struck me as busywork, however, and it has all the other disadvantages that've already been mentioned, in particular immutability. If bug updates are also always made available in e-mail, isn't this sufficient? We can do other things to cross-link the information too; e.g., change notifications could include the URLs of all the related bug-database entries. - Mark From mr at sun.com Thu Nov 8 18:11:40 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 10:11:40 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: andreas.sterbenz@sun.com; Mon, 05 Nov 2007 23:38:04 PST; <473019DC.5050105@sun.com> Message-ID: <20071108181140.DF30B78086@eggemoggin.niobe.net> > Date: Mon, 05 Nov 2007 23:38:04 -0800 > From: andreas.sterbenz at sun.com > iris.clark at sun.com wrote: >> >> For example: >> >> 4853841: Nervous text demo displays wrong version [iris, duke] >> >> This covers the common information but is that sufficient? I think > > I agree with your proposal (: ), but I believe that all > supplemental information about the bug should not be placed in the > changeset comments but in the bug database. That includes the names of the > reviewers. It is important that all information about a bug is collected > in one place, not two or three. That place needs to be the bug database. I disagree with you about where reviewers should be acknowledged. Reviewing code is tantamount to authorship. From one of our internal guideline documents (which is already in the process of being cleaned up for external use): When you review a change, remember that by doing so you are taking on full responsibility for the appropriateness and correctness of the change. If something goes wrong (e.g., the build breaks) and the change's author is unavailable, you will likely be asked to deal with the problem. If you don't think you're qualified to review a change, just say no. Changesets include author names, so they should include reviewer names as well. They should also include contributor names, if any, for changes contributed by developers who don't yet have commit access. - Mark From mr at sun.com Thu Nov 8 18:25:13 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 10:25:13 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: iris.clark@sun.com; Mon, 05 Nov 2007 22:16:54 PST; <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <20071108182513.17B6878086@eggemoggin.niobe.net> > Date: Mon, 05 Nov 2007 22:16:54 -0800 (PST) > From: iris.clark at sun.com > ... > > For example: > > 4853841: Nervous text demo displays wrong version > Review: iris, duke > Credit: mr - for extending the demo to accept arguments > > I favor the compactness of the first format; but the second is more > extensible and gives us a simple means to recognise key contributions > besides simple authorship or review. I think recognizing contributions from those who don't (yet) have commit rights is very important. Extensibility for the future is good too. I'm a little wary of a "credits" section turning into a long chunk of arbitrary text, in the extreme kind of like the infinitely-long credits crawl that you see at the end of most movies these days. The goal here isn't to give credit to every last person who helped with the change, but rather to acknowledge non-committers who contribute whole changes. I'd rather see just a simple acknowledgment listing the contributor's e-mail address, e.g., Contributed-by: Random Hacker We can change "Review:" to "Reviewed-by:" as well, to stress the analogy with RFC-822 and the fact that changeset comments aren't intended to be arbitrary text. - Mark From aph at redhat.com Thu Nov 8 18:25:16 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Nov 2007 18:25:16 +0000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071108174600.9E65B78086@eggemoggin.niobe.net> References: <18225.42455.104750.342011@zebedee.pink> <20071108174600.9E65B78086@eggemoggin.niobe.net> Message-ID: <18227.21644.774573.938391@zebedee.pink> Mark Reinhold writes: > > Date: Wed, 07 Nov 2007 11:47:35 +0000 > > From: Andrew Haley > > > ... > > > > I am trying to make sure that all the information about every change > > is in a searchable form that doesn't require special software. I'm > > trying to make sure that if (God forbid) a nuke fell on Sun central, > > everyone else would just carry on with their work, with all of the > > information they need easily to have. > > In general I think this is a good principle. > > > I'll explain what we do at GNU, and why I think it's a good thing. > > > > The comment we write for a change is written and submitted for review > > along with the patch. When the patch is approved, this pre-written > > comment is used for the version control commit. So, when you look at > > a patch submission you can immediately tie it with the commit. > > So does the comment describing the technical nature of the change ever > wind up anywhere else -- e.g., in a Bugzilla entry? That's right. Once the commit is done, the comment gets automatically copied into the Bugzilla entry. The version control system does this as a side-effect of the commit. The commit message is also mailed to everyone on the CC list for that bug. Here's an example: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14315 On that page is the initial bug report, the patch, some discussion, and the commit comment, along with URLs that point to the VCS. It's not perfect in that there isn't an automatically created link from the Bugzilla entry to the discussion on the mailing list. > The usual practice at Sun has been to put that kind of information > into the evaluation section of the bug report. That's fine too, but it would be nice to have all that CC'd to a mailing list. > Some teams have also put that information, or a variant of it, into > TeamWare delta or putback comments. That's always struck me as > busywork, however, and it has all the other disadvantages that've > already been mentioned, in particular immutability. > > If bug updates are also always made available in e-mail, isn't this > sufficient? We can do other things to cross-link the information > too; e.g., change notifications could include the URLs of all the > related bug-database entries. That sounds fine. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Andreas.Sterbenz at Sun.COM Thu Nov 8 18:36:01 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 08 Nov 2007 10:36:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071108181140.DF30B78086@eggemoggin.niobe.net> References: <20071108181140.DF30B78086@eggemoggin.niobe.net> Message-ID: <47335711.2010301@sun.com> Mark Reinhold wrote: > > I disagree with you about where reviewers should be acknowledged. > > Reviewing code is tantamount to authorship. From one of our internal > guideline documents (which is already in the process of being cleaned > up for external use): That's fine. And the names of the reviewers should be stored in the bug database, along with all the other information about the fix. Do you agree with that? If that's the case, the value of duplicating this information in the changeset comment seems of limited value to me. Andreas. From mr at sun.com Thu Nov 8 18:48:54 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 10:48:54 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: andreas.sterbenz@sun.com; Thu, 08 Nov 2007 10:36:01 PST; <47335711.2010301@sun.com> Message-ID: <20071108184854.C645478089@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 10:36:01 -0800 > From: andreas.sterbenz at sun.com > Mark Reinhold wrote: >> I disagree with you about where reviewers should be acknowledged. >> >> Reviewing code is tantamount to authorship. From one of our internal >> guideline documents (which is already in the process of being cleaned >> up for external use): > > That's fine. And the names of the reviewers should be stored in the bug > database, along with all the other information about the fix. Do you agree > with that? No. Authorship information should go with the code. - Mark From mr at sun.com Thu Nov 8 19:30:05 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 11:30:05 -0800 Subject: Should we rename the MASTER forest? Message-ID: <20071108193005.E301978089@eggemoggin.niobe.net> In the experimental JDK 7 forests on http://hg.openjdk.java.net we've carried over an old naming convention that we at Sun have used for all primary JDK TeamWare workspaces for many years. (The primary workspace is the one into which all group workspaces integrate, and from which the product is built by the release-engineering team.) That convention is to name these primary workspaces MASTER, in all caps, in order to stress their importance and help prevent accidental putbacks or, worse, corruption in the case of naive developers who cd directly into the MASTER tree and try to do work there. (Yes, this has happened, more than once.) These sorts of accidents could happen under TeamWare because workspaces are shared via NFS and are (essentially) world-writable. In the new world of Mercurial, of course, that's not the case. Our server-side infrastructure will, moreover, only allow trusted developers to push changes into repositories/forests. So there's no longer much reason to use the annoying name MASTER, and there's at least one reason not to: Issuing the obvious hg command to get a local clone of the MASTER, i.e., % hg fclone http://hg.openjdk.java.net/jdk7/MASTER will create a local forest named MASTER -- but of course it isn't the master, it's just a clone. Such names can propagate, too [1], leading to even wider potential confusion. Given all this I hereby propose that we rename the MASTER forest simply to "jdk7". That way an hg fclone will create a local forest with a more obvious name, and we can all give our shift keys a well-earned rest. Comments? (This may seem a trivial issue, but names are important, and once we go live with Mercurial it'll be difficult to change this one.) - Mark [1] http://www.jfrog.org/hg/openJDK/MASTER -- I'm sure Frederic wasn't trying to confuse anybody when he published this forest, he just did the obvious thing. From John.Rose at Sun.COM Thu Nov 8 19:35:35 2007 From: John.Rose at Sun.COM (John Rose) Date: Thu, 08 Nov 2007 11:35:35 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <7BB4CBB5-9605-49D0-93FD-6A34910EF782@sun.com> +1 from me. -- John From gnu_andrew at member.fsf.org Thu Nov 8 19:53:21 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 8 Nov 2007 19:53:21 +0000 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <17c6771e0711081153p6f4255a9jcc205ee364ebefd4@mail.gmail.com> On 08/11/2007, Mark Reinhold wrote: > > In the experimental JDK 7 forests on http://hg.openjdk.java.net we've > carried over an old naming convention that we at Sun have used for all > primary JDK TeamWare workspaces for many years. (The primary workspace > is the one into which all group workspaces integrate, and from which > the product is built by the release-engineering team.) > > That convention is to name these primary workspaces MASTER, in all caps, > in order to stress their importance and help prevent accidental putbacks > or, worse, corruption in the case of naive developers who cd directly > into the MASTER tree and try to do work there. (Yes, this has happened, > more than once.) > > These sorts of accidents could happen under TeamWare because workspaces > are shared via NFS and are (essentially) world-writable. In the new > world of Mercurial, of course, that's not the case. Our server-side > infrastructure will, moreover, only allow trusted developers to push > changes into repositories/forests. > > So there's no longer much reason to use the annoying name MASTER, and > there's at least one reason not to: Issuing the obvious hg command to > get a local clone of the MASTER, i.e., > > % hg fclone http://hg.openjdk.java.net/jdk7/MASTER > > will create a local forest named MASTER -- but of course it isn't the > master, it's just a clone. Such names can propagate, too [1], leading > to even wider potential confusion. > > Given all this I hereby propose that we rename the MASTER forest simply > to "jdk7". That way an hg fclone will create a local forest with a more > obvious name, and we can all give our shift keys a well-earned rest. > > Comments? > > (This may seem a trivial issue, but names are important, and once we go > live with Mercurial it'll be difficult to change this one.) > > - Mark > > > [1] http://www.jfrog.org/hg/openJDK/MASTER -- I'm sure Frederic wasn't > trying to confuse anybody when he published this forest, he just > did the obvious thing. > jdk7 seems a bit odd, given that presumably the mercurial repositories will live on beyond the release of version 7. How about simply jdk? Or am I missing some subtle point that means we can't simply mark a snapshot that was the jdk7 release? -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bradford.Wetmore at Sun.COM Thu Nov 8 19:53:29 2007 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Thu, 08 Nov 2007 11:53:29 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071108184854.C645478089@eggemoggin.niobe.net> References: <20071108184854.C645478089@eggemoggin.niobe.net> Message-ID: <47336939.8050106@sun.com> Mark Reinhold wrote: >> Mark Reinhold wrote: >>> I disagree with you about where reviewers should be acknowledged. >>> >>> Reviewing code is tantamount to authorship. From one of our internal >>> guideline documents (which is already in the process of being cleaned >>> up for external use): Absolutely. When anything breaks, as gatekeeper I head directly to *BOTH* author and reviewer(s). IMHO, if a fix has approval, the reviewers have implicitly stated they understood and agreed with what they were reviewing. >> That's fine. And the names of the reviewers should be stored in the bug >> database, along with all the other information about the fix. Do you agree >> with that? > > No. Authorship information should go with the code. Agreed. As a someone who occasionally has to put on the "archeologist" hat, this information needs to be readily available, and the changeset comment is the ideal place for it. Plus the push hooks can prevalidate the contents of the comment. I don't want to load/navigate through different tools only to find out the reviewer information was never captured. There are no checks with the current bug tracking/codereview mechanism. Yes, that could change "down the road" with the automated codereview tool being discussed in another thread, but that's still an extra step/server I have to go through, and requires that I be online. Brad From Xiomara.Jayasena at Sun.COM Thu Nov 8 20:01:57 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Thu, 08 Nov 2007 12:01:57 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <47336B35.5000806@Sun.COM> Mark Reinhold wrote: >Given all this I hereby propose that we rename the MASTER forest simply >to "jdk7". That way an hg fclone will create a local forest with a more >obvious name, and we can all give our shift keys a well-earned rest. > >Comments? > > I second this proposal. -Xiomara >(This may seem a trivial issue, but names are important, and once we go > live with Mercurial it'll be difficult to change this one.) > >- Mark > > From Andreas.Sterbenz at Sun.COM Thu Nov 8 20:06:07 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 08 Nov 2007 12:06:07 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <47336C2F.8020504@sun.com> Mark Reinhold wrote: > > Given all this I hereby propose that we rename the MASTER forest simply > to "jdk7". That way an hg fclone will create a local forest with a more > obvious name, and we can all give our shift keys a well-earned rest. So it would be called http://hg.openjdk.java.net/jdk7/jdk7/ or just http://hg.openjdk.java.net/jdk7/ ? If it's the latter, we'd have http://hg.openjdk.java.net/jdk7/ http://hg.openjdk.java.net/jdk7/corba/ http://hg.openjdk.java.net/jdk7/hotspot/ http://hg.openjdk.java.net/jdk7/jaxp/ ... right? Then what would the group forests be named? They are currently e.g. http://hg.openjdk.java.net/jdk7/awt/ which looks just like a repository that is part of the "master" forest. Andreas. From roman at kennke.org Thu Nov 8 20:13:58 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 08 Nov 2007 21:13:58 +0100 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <1194552838.15597.21.camel@mercury> Hi Mark, > Given all this I hereby propose that we rename the MASTER forest > simply > to "jdk7". One thing I don't understand is, why is something in the repository URL named with a release (-like) number? Is the repository only made for JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense to me. Why not simply drop the '7' and name it 'jdk'? My personal favorite is 'openjdk' though. IMO the URLs should read like: http://hg.openjdk.java.net/openjdk/ /Roman -- http://kennke.org/blog/ From David.Herron at Sun.COM Thu Nov 8 20:23:02 2007 From: David.Herron at Sun.COM (David Herron) Date: Thu, 08 Nov 2007 12:23:02 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <1194552838.15597.21.camel@mercury> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> Message-ID: <47337026.6040502@sun.com> Roman Kennke wrote: > Hi Mark, >> Given all this I hereby propose that we rename the MASTER forest >> simply >> to "jdk7". >> > One thing I don't understand is, why is something in the repository URL > named with a release (-like) number? Is the repository only made for > JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense > to me. Why not simply drop the '7' and name it 'jdk'? My personal > favorite is 'openjdk' though. IMO the URLs should read like: > > http://hg.openjdk.java.net/openjdk/ > > /Roman > > I'm thinking a similar thing. But, the team practices Mark alluded to also includes having a new MASTER for each release. There's the MASTER for 1.4, for 1.5, for 6, and for 7 and so on. I think that would mean over time the URL's would read http://hg.openjdk.java.net/openjdk7 http://hg.openjdk.java.net/openjdk8 http://hg.openjdk.java.net/openjdk9 ... - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Thu Nov 8 20:25:09 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 8 Nov 2007 20:25:09 +0000 Subject: Should we rename the MASTER forest? In-Reply-To: <47337026.6040502@sun.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> Message-ID: <17c6771e0711081225q71e02948t9e4dda9bb07b2aff@mail.gmail.com> On 08/11/2007, David Herron wrote: > > Roman Kennke wrote: > > Hi Mark, > > Given all this I hereby propose that we rename the MASTER forest > simply > to "jdk7". > > One thing I don't understand is, why is something in the repository URL > named with a release (-like) number? Is the repository only made for > JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense > to me. Why not simply drop the '7' and name it 'jdk'? My personal > favorite is 'openjdk' though. IMO the URLs should read like: > > http://hg.openjdk.java.net/openjdk/ > > /Roman > > > > I'm thinking a similar thing. > > But, the team practices Mark alluded to also includes having a new MASTER > for each release. There's the MASTER for 1.4, for 1.5, for 6, and for 7 > and so on. I think that would mean over time the URL's would read > > http://hg.openjdk.java.net/openjdk7 > http://hg.openjdk.java.net/openjdk8 > http://hg.openjdk.java.net/openjdk9 > ... > > - David Herron > > Is there a reason for that? Because it seems non-sensical to me and I guess to all other non-Sun folks. -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman at kennke.org Thu Nov 8 20:44:21 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 08 Nov 2007 21:44:21 +0100 Subject: Should we rename the MASTER forest? In-Reply-To: <47337026.6040502@sun.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> Message-ID: <1194554661.15597.26.camel@mercury> Hi David, Am Donnerstag, den 08.11.2007, 12:23 -0800 schrieb David Herron: > Roman Kennke wrote: > > Hi Mark, > > > Given all this I hereby propose that we rename the MASTER forest > > > simply > > > to "jdk7". > > > > > One thing I don't understand is, why is something in the repository URL > > named with a release (-like) number? Is the repository only made for > > JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense > > to me. Why not simply drop the '7' and name it 'jdk'? My personal > > favorite is 'openjdk' though. IMO the URLs should read like: > > > > http://hg.openjdk.java.net/openjdk/ > > > > /Roman > > > > > > > I'm thinking a similar thing. > > But, the team practices Mark alluded to also includes having a new > MASTER for each release. There's the MASTER for 1.4, for 1.5, for 6, > and for 7 and so on. I think that would mean over time the URL's > would read > > http://hg.openjdk.java.net/openjdk7 > http://hg.openjdk.java.net/openjdk8 > http://hg.openjdk.java.net/openjdk9 > ... So, if I understand it correctly, you are 'branching' at the beginning of a release cycle, instead after the release. And when a new release cycle starts, you would clone jdkX to jdkX+1 ? Strange practice for my taste... /Roman -- http://kennke.org/blog/ From Xiomara.Jayasena at Sun.COM Thu Nov 8 20:47:12 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Thu, 08 Nov 2007 12:47:12 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <17c6771e0711081225q71e02948t9e4dda9bb07b2aff@mail.gmail.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> <17c6771e0711081225q71e02948t9e4dda9bb07b2aff@mail.gmail.com> Message-ID: <473375D0.8090904@Sun.COM> Andrew John Hughes wrote: > > > On 08/11/2007, *David Herron* > wrote: > > Roman Kennke wrote: > >>Hi Mark, >> >>>Given all this I hereby propose that we rename the MASTER forest >>>simply >>>to "jdk7". >>> >>> >>One thing I don't understand is, why is something in the repository URL >>named with a release (-like) number? Is the repository only made for >>JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense >> >>to me. Why not simply drop the '7' and name it 'jdk'? My personal >>favorite is 'openjdk' though. IMO the URLs should read like: >> >> >>http://hg.openjdk.java.net/openjdk/ >> >>/Roman >> >> >> > > > I'm thinking a similar thing. > > But, the team practices Mark alluded to also includes having a new > MASTER for each release. There's the MASTER for 1.4, for 1.5, for > 6, and for 7 and so on. I think that would mean over time the > URL's would read > > http://hg.openjdk.java.net/openjdk7 > http://hg.openjdk.java.net/openjdk8 > http://hg.openjdk.java.net/openjdk9 > ... > > - David Herron > > > > Is there a reason for that? Because it seems non-sensical to me and I > guess to all other non-Sun folks. How so? There are parallel releases going on or active at the same time. For instance there would be a URL for jdk6 and jdk7 in the above. I am unclear how that is unclear to you? ;-) -Xiomara > -- > Andrew :-) > > Help end the Java Trap! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net From Xiomara.Jayasena at Sun.COM Thu Nov 8 21:01:16 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Thu, 08 Nov 2007 13:01:16 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <473375D0.8090904@Sun.COM> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> <17c6771e0711081225q71e02948t9e4dda9bb07b2aff@mail.gmail.com> <473375D0.8090904@Sun.COM> Message-ID: <4733791C.4020603@Sun.COM> Xiomara.Jayasena at Sun.COM wrote: > Andrew John Hughes wrote: > >> >> >> On 08/11/2007, *David Herron* > > wrote: >> >> Roman Kennke wrote: >> >>> Hi Mark, >>> >>>> Given all this I hereby propose that we rename the MASTER forest >>>> simply >>>> to "jdk7". >>>> >>> >>> One thing I don't understand is, why is something in the repository URL >>> named with a release (-like) number? Is the repository only made for >>> JDK7, and we start a fresh one for JDK8? Doesn't seem to make much >>> sense >>> >>> to me. Why not simply drop the '7' and name it 'jdk'? My personal >>> favorite is 'openjdk' though. IMO the URLs should read like: >>> >>> >>> http://hg.openjdk.java.net/openjdk/ >>> >>> /Roman >>> >>> >>> >> >> >> I'm thinking a similar thing. >> >> But, the team practices Mark alluded to also includes having a new >> MASTER for each release. There's the MASTER for 1.4, for 1.5, for >> 6, and for 7 and so on. I think that would mean over time the >> URL's would read >> >> http://hg.openjdk.java.net/openjdk7 >> http://hg.openjdk.java.net/openjdk8 >> http://hg.openjdk.java.net/openjdk9 >> ... >> >> - David Herron >> >> >> >> Is there a reason for that? Because it seems non-sensical to me and I >> guess to all other non-Sun folks. > > > How so? There are parallel releases going on or active at the same time. > > For instance there would be a URL for jdk6 and jdk7 in the above. > I am unclear how that is unclear to you? ;-) Typo on the smiley it was meant to be a ;-( -Xiomara > > -Xiomara > >> -- >> Andrew :-) >> >> Help end the Java Trap! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net > > > From David.Herron at Sun.COM Thu Nov 8 21:31:54 2007 From: David.Herron at Sun.COM (David Herron) Date: Thu, 08 Nov 2007 13:31:54 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <1194554661.15597.26.camel@mercury> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> <1194554661.15597.26.camel@mercury> Message-ID: <4733804A.5090908@sun.com> Roman Kennke wrote: > Hi David, > > Am Donnerstag, den 08.11.2007, 12:23 -0800 schrieb David Herron: > >> Roman Kennke wrote: >> >>> Hi Mark, >>> >>>> Given all this I hereby propose that we rename the MASTER forest >>>> simply to "jdk7". >>>> >>> One thing I don't understand is, why is something in the repository URL >>> named with a release (-like) number? Is the repository only made for >>> JDK7, and we start a fresh one for JDK8? Doesn't seem to make much sense >>> to me. Why not simply drop the '7' and name it 'jdk'? My personal >>> favorite is 'openjdk' though. IMO the URLs should read like: >>> >>> http://hg.openjdk.java.net/openjdk/ >>> >>> /Roman >>> >> I'm thinking a similar thing. >> >> But, the team practices Mark alluded to also includes having a new >> MASTER for each release. There's the MASTER for 1.4, for 1.5, for 6, >> and for 7 and so on. I think that would mean over time the URL's >> would read >> >> http://hg.openjdk.java.net/openjdk7 >> http://hg.openjdk.java.net/openjdk8 >> http://hg.openjdk.java.net/openjdk9 >> ... >> > So, if I understand it correctly, you are 'branching' at the beginning > of a release cycle, instead after the release. And when a new release > cycle starts, you would clone jdkX to jdkX+1 ? Strange practice for my > taste... > > /Roman This way the workspace contains the history of changes for the given release cycle. At the end of a release there's a clone created that's the beginning of the next release. So it's a matter of perspective whether the clone is at the "end" or "start" of a release. This practice comes partly from the features of TeamWare in that it supports multiple independent workspaces. It's common practice to clone workspaces to do work. This is different in many ways from SCM systems that use a central repository like CVS does. Where in CVS you would tag the repository at a given release, and then do per-release work in a branch... this is where we instead use multiple repositories. Speaking for myself I've found branches and tags in CVS to be confusing, despite having used CVS of and on for 15 yrs, but multiple repositories in TeamWare is very straightforward. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Armstrong at Sun.COM Thu Nov 8 21:39:00 2007 From: Eric.Armstrong at Sun.COM (Eric Armstrong) Date: Thu, 08 Nov 2007 13:39:00 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <4733804A.5090908@sun.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> <1194554661.15597.26.camel@mercury> <4733804A.5090908@sun.com> Message-ID: <473381F4.6010009@sun.com> David Herron wrote: >>> ...over time the URL's would read >>> >>> http://hg.openjdk.java.net/openjdk7 >>> http://hg.openjdk.java.net/openjdk8 >>> http://hg.openjdk.java.net/openjdk9 >>> ... > > This is different in many ways from SCM systems that use a central > repository like CVS does. Where in CVS you would tag the repository at > a given release, and then do per-release work in a branch... this is > where we instead use multiple repositories. Speaking for myself I've > found branches and tags in CVS to be confusing, despite having used CVS > of and on for 15 yrs, but multiple repositories in TeamWare is very > straightforward. > Glad to hear I wasn't the only one who was confused. I am wondering about bug fixes though. Was it easier or harder in CVS to apply a fix across multiple branches? I know we're not worrying about docs yet, but the need for replicating changes in multiple repositories is already straining an over-taxed docs department. -- Eric Armstrong, Document Systems Architect, Sun Microsystems http://blogs.sun.com/coolstuff http://www.artima.com/weblogs/index.jsp?blogger=cooltools From Kelly.Ohair at Sun.COM Thu Nov 8 21:45:00 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 08 Nov 2007 13:45:00 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <7BB4CBB5-9605-49D0-93FD-6A34910EF782@sun.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <7BB4CBB5-9605-49D0-93FD-6A34910EF782@sun.com> Message-ID: <4733835C.3010702@sun.com> +1 from me too. -kto From mr at sun.com Thu Nov 8 21:54:42 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 13:54:42 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: gnu_andrew@member.fsf.org; Thu, 08 Nov 2007 19:53:21 GMT; <17c6771e0711081153p6f4255a9jcc205ee364ebefd4@mail.gmail.com> Message-ID: <20071108215442.5F82978089@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 19:53:21 +0000 > From: Andrew John Hughes > jdk7 seems a bit odd, given that presumably the mercurial repositories will > live on beyond the release of version 7. How about simply jdk? Or am I > missing some subtle point that means we can't simply mark a snapshot that > was the jdk7 release? Good question! Yes, we could tag the final changeset in each tree, but ... Our usual practice has been to freeze the master TeamWare workspaces for each release when that release goes final. Successor releases, whether they're small update releases or the next big feature release, are developed in their own workspaces, which start out as clones of the original master. This is, yes, different from the way that people tend to use centralized SCMs such as CVS and Subversion. Transposing this to Mercurial: When JDK 7 ships then the jdk7 master forest will be archived, and work on JDK 8 will begin in a jdk8 forest, which will initially be a clone of jdk7. One could argue that this practice arose in response to the inherent weaknesses of TeamWare, and that's largely true. There are, however, at least two reasons to retain it: - Familiarity - This counts for a lot. We're already forcibly stretching the brains of Sun engineers to transition from TeamWare to Mercurial; let's not stretch them more than absolutely needed. - Paranoia - So far Mercurial has been very robust in our experience, but there is nonetheless a certain comfort in knowing that a read-only, archived copy of every release forest is readily available just in case something goes very wrong. (Yes, of course we do backups too, but restoring really old backups tends to be painful.) None of this is cast in stone. If down the road we find better reasons to have just one big JDK master forest then we can pretty easily make that happen. To be clear, the URL for the JDK 7 master forests is currently http://hg.openjdk.java.net/jdk7/MASTER but with my proposal will change to http://hg.openjdk.java.net/jdk7/jdk7 and live alongside the other JDK 7 integration forests: http://hg.openjdk.java.net/jdk7/2d http://hg.openjdk.java.net/jdk7/awt http://hg.openjdk.java.net/jdk7/build http://hg.openjdk.java.net/jdk7/corba http://hg.openjdk.java.net/jdk7/hotspot http://hg.openjdk.java.net/jdk7/... - Mark From neal at gafter.com Thu Nov 8 22:02:23 2007 From: neal at gafter.com (Neal Gafter) Date: Thu, 8 Nov 2007 14:02:23 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108215442.5F82978089@eggemoggin.niobe.net> References: <17c6771e0711081153p6f4255a9jcc205ee364ebefd4@mail.gmail.com> <20071108215442.5F82978089@eggemoggin.niobe.net> Message-ID: <15e8b9d20711081402w33a2bd08s9a285c826b31a95a@mail.gmail.com> On Nov 8, 2007 1:54 PM, Mark Reinhold wrote: > Our usual practice has been to freeze the master TeamWare workspaces for > each release when that release goes final. Successor releases, whether > they're small update releases or the next big feature release, are > developed in their own workspaces, which start out as clones of the > original master. This is, yes, different from the way that people tend > to use centralized SCMs such as CVS and Subversion. > > Transposing this to Mercurial: When JDK 7 ships then the jdk7 master > forest will be archived, and work on JDK 8 will begin in a jdk8 forest, > which will initially be a clone of jdk7. One problem with this approach is that work on the next release cannot begin until the powers that control these workspaces are ready for work to begin on the next major release. Within Sun, that has resulted in engineers being unable to make significant changes for the following release until some time after the current release is completed. This is particularly painful during the final ramp-down months of a release, when only critical changes are accepted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Thu Nov 8 22:20:54 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 14:20:54 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: neal@gafter.com; Thu, 08 Nov 2007 14:02:23 PST; <15e8b9d20711081402w33a2bd08s9a285c826b31a95a@mail.gmail.com> Message-ID: <20071108222054.354BD78089@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 14:02:23 -0800 > From: Neal Gafter > On Nov 8, 2007 1:54 PM, Mark Reinhold wrote: >> Transposing this to Mercurial: When JDK 7 ships then the jdk7 master >> forest will be archived, and work on JDK 8 will begin in a jdk8 forest, >> which will initially be a clone of jdk7. > > One problem with this approach is that work on the next release cannot begin > until the powers that control these workspaces are ready for work to begin > on the next major release. Within Sun, that has resulted in engineers being > unable to make significant changes for the following release until some time > after the current release is completed. No, it has resulted in Sun engineers not being able to get QA to test their changes for the next release until the QA team is finished with the release that's about to ship. Sun engineers have always been able to work ahead of the schedule by working in their own private TeamWare workspaces, or in shared group workspaces. > This is particularly painful during > the final ramp-down months of a release, when only critical changes are > accepted. All the more reason for each release to have its very own forest. It's much easier to ramp down change in an entire forest rather than just in a particular branch of that forest. - Mark From Jonathan.Gibbons at Sun.COM Thu Nov 8 22:45:52 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 08 Nov 2007 14:45:52 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108193005.E301978089@eggemoggin.niobe.net> References: <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <473391A0.5020802@sun.com> I'm going to buck the trend and go -1 on this one. The set of repositories is already confusing enough, and changing a name which means something (MASTER) into a more generic name that is already used in the path (jdk7) seem, well, less than desirable, to use words for polite company. If there is a problem with fclones creating more MASTER repositories, you can fix that by putting a dummy name component after MASTER (perhaps that is where to put jdk7). At the same time you could mirror the structure into the other repositories and add "integration" into the path, eg jdk7/integration/tl/* -- Jon Mark Reinhold wrote: > In the experimental JDK 7 forests on http://hg.openjdk.java.net we've > carried over an old naming convention that we at Sun have used for all > primary JDK TeamWare workspaces for many years. (The primary workspace > is the one into which all group workspaces integrate, and from which > the product is built by the release-engineering team.) > > That convention is to name these primary workspaces MASTER, in all caps, > in order to stress their importance and help prevent accidental putbacks > or, worse, corruption in the case of naive developers who cd directly > into the MASTER tree and try to do work there. (Yes, this has happened, > more than once.) > > These sorts of accidents could happen under TeamWare because workspaces > are shared via NFS and are (essentially) world-writable. In the new > world of Mercurial, of course, that's not the case. Our server-side > infrastructure will, moreover, only allow trusted developers to push > changes into repositories/forests. > > So there's no longer much reason to use the annoying name MASTER, and > there's at least one reason not to: Issuing the obvious hg command to > get a local clone of the MASTER, i.e., > > % hg fclone http://hg.openjdk.java.net/jdk7/MASTER > > will create a local forest named MASTER -- but of course it isn't the > master, it's just a clone. Such names can propagate, too [1], leading > to even wider potential confusion. > > Given all this I hereby propose that we rename the MASTER forest simply > to "jdk7". That way an hg fclone will create a local forest with a more > obvious name, and we can all give our shift keys a well-earned rest. > > Comments? > > (This may seem a trivial issue, but names are important, and once we go > live with Mercurial it'll be difficult to change this one.) > > - Mark > > > [1] http://www.jfrog.org/hg/openJDK/MASTER -- I'm sure Frederic wasn't > trying to confuse anybody when he published this forest, he just > did the obvious thing. > From gnu_andrew at member.fsf.org Thu Nov 8 22:49:03 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 8 Nov 2007 22:49:03 +0000 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108215442.5F82978089@eggemoggin.niobe.net> References: <17c6771e0711081153p6f4255a9jcc205ee364ebefd4@mail.gmail.com> <20071108215442.5F82978089@eggemoggin.niobe.net> Message-ID: <17c6771e0711081449qa198951gf2de72796406df1b@mail.gmail.com> On 08/11/2007, Mark Reinhold wrote: > > > Date: Thu, 08 Nov 2007 19:53:21 +0000 > > From: Andrew John Hughes > > > jdk7 seems a bit odd, given that presumably the mercurial repositories > will > > live on beyond the release of version 7. How about simply jdk? Or am I > > missing some subtle point that means we can't simply mark a snapshot > that > > was the jdk7 release? > > Good question! > > Yes, we could tag the final changeset in each tree, but ... > > Our usual practice has been to freeze the master TeamWare workspaces for > each release when that release goes final. Successor releases, whether > they're small update releases or the next big feature release, are > developed in their own workspaces, which start out as clones of the > original master. This is, yes, different from the way that people tend > to use centralized SCMs such as CVS and Subversion. > > Transposing this to Mercurial: When JDK 7 ships then the jdk7 master > forest will be archived, and work on JDK 8 will begin in a jdk8 forest, > which will initially be a clone of jdk7. > > One could argue that this practice arose in response to the inherent > weaknesses of TeamWare, and that's largely true. There are, however, > at least two reasons to retain it: > > - Familiarity - This counts for a lot. We're already forcibly > stretching the brains of Sun engineers to transition from TeamWare > to Mercurial; let's not stretch them more than absolutely needed. > > - Paranoia - So far Mercurial has been very robust in our experience, > but there is nonetheless a certain comfort in knowing that a > read-only, archived copy of every release forest is readily available > just in case something goes very wrong. (Yes, of course we do > backups too, but restoring really old backups tends to be painful.) > > None of this is cast in stone. If down the road we find better reasons > to have just one big JDK master forest then we can pretty easily make > that happen. > > To be clear, the URL for the JDK 7 master forests is currently > > http://hg.openjdk.java.net/jdk7/MASTER > > but with my proposal will change to > > http://hg.openjdk.java.net/jdk7/jdk7 > > and live alongside the other JDK 7 integration forests: > > http://hg.openjdk.java.net/jdk7/2d > http://hg.openjdk.java.net/jdk7/awt > http://hg.openjdk.java.net/jdk7/build > http://hg.openjdk.java.net/jdk7/corba > http://hg.openjdk.java.net/jdk7/hotspot > http://hg.openjdk.java.net/jdk7/... > > - Mark > Ok, I'll admit I'm still sceptical about this, but let's see how it works out. I don't see why we need to repeat the name 'jdk7' for master though if it's already in the path. Why not jdk7/jdk? -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Thu Nov 8 23:30:42 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 15:30:42 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: gnu_andrew@member.fsf.org; Thu, 08 Nov 2007 22:49:03 GMT; <17c6771e0711081449qa198951gf2de72796406df1b@mail.gmail.com> Message-ID: <20071108233042.A939A78089@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 22:49:03 +0000 > From: Andrew John Hughes > Ok, I'll admit I'm still sceptical about this, but let's see how it works > out. I don't see why we need to repeat the name 'jdk7' for master though if > it's already in the path. Why not jdk7/jdk? Because once you'd cloned it you'd find a jdk/jdk directory, and that could be really confusing. Redundancy in the URL seems easier to take, since it won't be replicated locally. - Mark From Peter.Kessler at Sun.COM Thu Nov 8 23:33:23 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 08 Nov 2007 15:33:23 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108215442.5F82978089@eggemoggin.niobe.net> References: <20071108215442.5F82978089@eggemoggin.niobe.net> Message-ID: <47339CC3.2000000@Sun.COM> Mark Reinhold wrote: >> Date: Thu, 08 Nov 2007 19:53:21 +0000 >> From: Andrew John Hughes > >> jdk7 seems a bit odd, given that presumably the mercurial repositories will >> live on beyond the release of version 7. How about simply jdk? Or am I >> missing some subtle point that means we can't simply mark a snapshot that >> was the jdk7 release? > > Good question! > > Yes, we could tag the final changeset in each tree, but ... > > Our usual practice has been to freeze the master TeamWare workspaces for > each release when that release goes final. Successor releases, whether > they're small update releases or the next big feature release, are > developed in their own workspaces, which start out as clones of the > original master. This is, yes, different from the way that people tend > to use centralized SCMs such as CVS and Subversion. > > Transposing this to Mercurial: When JDK 7 ships then the jdk7 master > forest will be archived, and work on JDK 8 will begin in a jdk8 forest, > which will initially be a clone of jdk7. > > One could argue that this practice arose in response to the inherent > weaknesses of TeamWare, and that's largely true. There are, however, > at least two reasons to retain it: > > - Familiarity - This counts for a lot. We're already forcibly > stretching the brains of Sun engineers to transition from TeamWare > to Mercurial; let's not stretch them more than absolutely needed. > > - Paranoia - So far Mercurial has been very robust in our experience, > but there is nonetheless a certain comfort in knowing that a > read-only, archived copy of every release forest is readily available > just in case something goes very wrong. (Yes, of course we do > backups too, but restoring really old backups tends to be painful.) > > None of this is cast in stone. If down the road we find better reasons > to have just one big JDK master forest then we can pretty easily make > that happen. > > To be clear, the URL for the JDK 7 master forests is currently > > http://hg.openjdk.java.net/jdk7/MASTER > > but with my proposal will change to > > http://hg.openjdk.java.net/jdk7/jdk7 > > and live alongside the other JDK 7 integration forests: > > http://hg.openjdk.java.net/jdk7/2d > http://hg.openjdk.java.net/jdk7/awt > http://hg.openjdk.java.net/jdk7/build > http://hg.openjdk.java.net/jdk7/corba > http://hg.openjdk.java.net/jdk7/hotspot > http://hg.openjdk.java.net/jdk7/... > > - Mark The VM team (the hotspot/ subdirectory) has tended to work the other way: we have a repository we are all working on and when we get near a release we make a clone of that and call it HotSpot-N. But the main repository keeps moving towards HotSpot-N+1. That means that bug fixes that are needed in HotSpot-N have to be forward-ported to the main repository. Or, more likely, fixed in the main repository and patched back to HotSpot-N. I think the need to fix things in two places will always be with us, no matter which way we clone the repositories. But as Neal points out, witht the main repository continuing forward, the engineers don't sit on their hands (or on private, untested workspaces) because management wants a release. (I think the allocation of testing resources is an orthogonal issue, but I understand QA's reluctance to test individual engineer workspaces.) If the top-level repository is called jdk, then it's weird that there's a jdk/jdk subdirectory. Can we think of a better name for that? jdk/jdk certainly isn't the whole JDK, since it doesn't contain the VM, langtools, or the other important bits. I'd let the people that own that code come up with a name for it. I understand the impetus to call the top-level repository openjdk. At first I thought that would be confusing for the Sun engineers that still have to deal with the parts of the JDK that aren't open yet. But on second thought it might prevent accidents to have the stuff that's open in a directory with "open" in its name. In the short term that might also remind people that OpenJDK is just the open parts of the JDK, because of the parts that are still encumbered (few and getting fewer). My $0.02. ... peter From Dmitri.Trembovetski at Sun.COM Thu Nov 8 23:41:32 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 08 Nov 2007 15:41:32 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <47339CC3.2000000@Sun.COM> References: <20071108215442.5F82978089@eggemoggin.niobe.net> <47339CC3.2000000@Sun.COM> Message-ID: <47339EAC.60106@Sun.COM> Peter B. Kessler wrote: > The VM team (the hotspot/ subdirectory) has tended to work the other > way: we have a repository we are all working on and when we get near > a release we make a clone of that and call it HotSpot-N. But the > main repository keeps moving towards HotSpot-N+1. > > That means that bug fixes that are needed in HotSpot-N have to be > forward-ported to the main repository. Or, more likely, fixed in > the main repository and patched back to HotSpot-N. I think the need > to fix things in two places will always be with us, no matter which > way we clone the repositories. Java2D team works the same way. Our team workspace never changed, we just forked off branches for specific releases or milestones (beta, beta2, rc) when needed, and reparented it when a new master workspace for the next release was created. Which was pretty neat since we have full history of putbacks into our team workspace (in Teamware the history of _the workspace_ doesn't propagate with putbacks, only individual files). Of course this is less of an advantage with Hg. Thank you, Dmitri From mr at sun.com Thu Nov 8 23:52:18 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 08 Nov 2007 15:52:18 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: peter.kessler@sun.com; Thu, 08 Nov 2007 15:33:23 PST; <47339CC3.2000000@Sun.COM> Message-ID: <20071108235218.9377B78089@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 15:33:23 -0800 > From: peter.kessler at sun.com > ... I think the need > to fix things in two places will always be with us, no matter which > way we clone the repositories. Agreed. > But as Neal points out, witht the main repository continuing forward, > the engineers don't sit on their hands (or on private, untested > workspaces) because management wants a release. (I think the allocation > of testing resources is an orthogonal issue, but I understand QA's > reluctance to test individual engineer workspaces.) It's not an orthogonal issue. In the past we've delayed the creation of master workspaces for new feature releases precisely because QA resources weren't available to do the PIT (pre-integration testing) runs needed to qualify changegroups for integration into the master. That's been interpreted by some as a message not to do any development work; I've never quite understood why. > If the top-level repository is called jdk, then it's weird that > there's a jdk/jdk subdirectory. Can we think of a better name for > that? jdk/jdk certainly isn't the whole JDK, since it doesn't > contain the VM, langtools, or the other important bits. I'd let > the people that own that code come up with a name for it. A bunch of us working on the Mercurial migration wracked our brains for weeks trying to come up with a better name for that tree. Suggestions are still welcome (the sooner the better, obviously). > I understand the impetus to call the top-level repository openjdk. > At first I thought that would be confusing for the Sun engineers that > still have to deal with the parts of the JDK that aren't open yet. > But on second thought it might prevent accidents to have the stuff > that's open in a directory with "open" in its name. In the short > term that might also remind people that OpenJDK is just the open > parts of the JDK, because of the parts that are still encumbered > (few and getting fewer). The problem is that Sun engineers who do deal with closed code would routinely be creating forests named "openjdk" that contain trees of closed code. That sounds really confusing. - Mark From neal at gafter.com Fri Nov 9 00:32:59 2007 From: neal at gafter.com (Neal Gafter) Date: Thu, 8 Nov 2007 16:32:59 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071108235218.9377B78089@eggemoggin.niobe.net> References: <47339CC3.2000000@Sun.COM> <20071108235218.9377B78089@eggemoggin.niobe.net> Message-ID: <15e8b9d20711081632o6704fa63p8e1712540e883760@mail.gmail.com> On Nov 8, 2007 3:52 PM, Mark Reinhold wrote: > > But as Neal points out, witht the main repository continuing forward, > > the engineers don't sit on their hands (or on private, untested > > workspaces) because management wants a release. (I think the allocation > > of testing resources is an orthogonal issue, but I understand QA's > > reluctance to test individual engineer workspaces.) > > It's not an orthogonal issue. In the past we've delayed the creation of > master workspaces for new feature releases precisely because QA resources > weren't available to do the PIT (pre-integration testing) runs needed to > qualify changegroups for integration into the master. That's been > interpreted by some as a message not to do any development work; I've > never quite understood why. The alternative is for everyone to hold the changes in our private or group workspaces, and suffer integration hell when a real master workspace finally arrives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Sterbenz at Sun.COM Fri Nov 9 01:12:08 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 08 Nov 2007 17:12:08 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071108184854.C645478089@eggemoggin.niobe.net> References: <20071108184854.C645478089@eggemoggin.niobe.net> Message-ID: <4733B3E8.6050801@sun.com> Mark Reinhold wrote: >> Date: Thu, 08 Nov 2007 10:36:01 -0800 >> From: andreas.sterbenz at sun.com > >> Mark Reinhold wrote: >>> I disagree with you about where reviewers should be acknowledged. >>> >>> Reviewing code is tantamount to authorship. From one of our internal >>> guideline documents (which is already in the process of being cleaned >>> up for external use): >> That's fine. And the names of the reviewers should be stored in the bug >> database, along with all the other information about the fix. Do you agree >> with that? > > No. Authorship information should go with the code. Exactly because that information is important it should be stored in the bug database, where all other information about the bug is stored [*], the location of which is well known to everyone and not just the developers working on the JDK, which can be queried using a web interface, etc. Capturing everything in the bug database except code reviewers does not seem like a good idea to me. It is probably a bit more difficult to ensure that the correct information is in the bug database than to validate the changeset comments, but it should be possible for the hooks to query it and verify that the relevant information is present (e.g. must have a comment that includes the text "Reviewed-by: X"). Andreas. [*] except the actual code changes From roman.kennke at aicas.com Fri Nov 9 09:00:46 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 09 Nov 2007 10:00:46 +0100 Subject: Should we rename the MASTER forest? In-Reply-To: <47339CC3.2000000@Sun.COM> References: <20071108215442.5F82978089@eggemoggin.niobe.net> <47339CC3.2000000@Sun.COM> Message-ID: <1194598846.6835.3.camel@mercury> Hi there, > The VM team (the hotspot/ subdirectory) has tended to work the other > way: we have a repository we are all working on and when we get near > a release we make a clone of that and call it HotSpot-N. But the > main repository keeps moving towards HotSpot-N+1. Seems like with Mercurial it doesn't really matter that much if we go the centralized approach of having one trunk from which the release branches are cloned or if the next development branch is cloned from the current release. The effect should be the same for all purposes. > If the top-level repository is called jdk, then it's weird that > there's a jdk/jdk subdirectory. Can we think of a better name for > that? jdk/jdk certainly isn't the whole JDK, since it doesn't > contain the VM, langtools, or the other important bits. I'd let > the people that own that code come up with a name for it. What about 'classlibs' for the class libs, rather than jdk? /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 roman.kennke at aicas.com Fri Nov 9 09:01:50 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 09 Nov 2007 10:01:50 +0100 Subject: Should we rename the MASTER forest? In-Reply-To: <473381F4.6010009@sun.com> References: <20071108193005.E301978089@eggemoggin.niobe.net> <1194552838.15597.21.camel@mercury> <47337026.6040502@sun.com> <1194554661.15597.26.camel@mercury> <4733804A.5090908@sun.com> <473381F4.6010009@sun.com> Message-ID: <1194598910.6835.5.camel@mercury> Hi there, Am Donnerstag, den 08.11.2007, 13:39 -0800 schrieb Eric Armstrong: > David Herron wrote: > >>> ...over time the URL's would read > >>> > >>> http://hg.openjdk.java.net/openjdk7 > >>> http://hg.openjdk.java.net/openjdk8 > >>> http://hg.openjdk.java.net/openjdk9 > >>> ... > > > > > This is different in many ways from SCM systems that use a central > > repository like CVS does. Where in CVS you would tag the repository at > > a given release, and then do per-release work in a branch... this is > > where we instead use multiple repositories. Speaking for myself I've > > found branches and tags in CVS to be confusing, despite having used CVS > > of and on for 15 yrs, but multiple repositories in TeamWare is very > > straightforward. > > > Glad to hear I wasn't the only one who was confused. > I am wondering about bug fixes though. Was it easier > or harder in CVS to apply a fix across multiple branches? It was much harder. Actually I found it almost impossible to do reasonable working merges from several branches. /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 gnu_andrew at member.fsf.org Fri Nov 9 09:58:29 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 9 Nov 2007 09:58:29 +0000 Subject: Should we rename the MASTER forest? In-Reply-To: <1194598846.6835.3.camel@mercury> References: <20071108215442.5F82978089@eggemoggin.niobe.net> <47339CC3.2000000@Sun.COM> <1194598846.6835.3.camel@mercury> Message-ID: <17c6771e0711090158n1def305y911b78cb1c117d11@mail.gmail.com> On 09/11/2007, Roman Kennke wrote: > > Hi there, > > > The VM team (the hotspot/ subdirectory) has tended to work the other > > way: we have a repository we are all working on and when we get near > > a release we make a clone of that and call it HotSpot-N. But the > > main repository keeps moving towards HotSpot-N+1. > > Seems like with Mercurial it doesn't really matter that much if we go > the centralized approach of having one trunk from which the release > branches are cloned or if the next development branch is cloned from the > current release. The effect should be the same for all purposes. > > > > If the top-level repository is called jdk, then it's weird that > > there's a jdk/jdk subdirectory. Can we think of a better name for > > that? jdk/jdk certainly isn't the whole JDK, since it doesn't > > contain the VM, langtools, or the other important bits. I'd let > > the people that own that code come up with a name for it. > > What about 'classlibs' for the class libs, rather than jdk? > > /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 > > classlibs seems a better name, I think 'jdk' is a legacy name from before langtools and friends were split out (but then again, this never included hotspot). -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Yuri.Nesterenko at Sun.COM Fri Nov 9 11:28:54 2007 From: Yuri.Nesterenko at Sun.COM (Yuri Nesterenko) Date: Fri, 09 Nov 2007 14:28:54 +0300 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> References: <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <20071109112854.GC30903@frigate.russia.sun.com> Should there be a convention for the name of author? A person should be easily found by the name. I'm asking that because the name will be written in developer's .hgrc file and [another name or nick] used for push. No sense for me to put there 'yuri' as in my OpenJDK public keys collection: it's too common a name in our part of the world. E-mail? Will it be obfuscated? At least a gatekeeper should be able to quickly find the submitter without research. Thanks, -Yuri On Mon, Nov 05, 2007 at 10:16:54PM -0800, iris.clark at sun.com wrote: > Hi. > > As you know, the experimental OpenJDK repositories for JDK 7 are > available [1]. In anticipation of getting the repositories live, we > need to decide what our convention for changeset comments should be. > The required format of the comments will be enforced whenever the > changeset is pushed into the JDK 6/7 master or group repository > forests. Other Projects may copy these conventions, adopt some other > conventions, or have no conventions, depending upon their goals. > > In the old system, depending on the group integration tree, several > formats were in use. Here's the common information: > > - name of the person making the change > - bugid (a 7-digit number allocated by the Sun bug database) > - complete synopsis of the bug > - comma-separated list of reviewers of the change (typically > either username or e-mail address) > > Optional information which appears in some trees includes: > > - information about existenace or feasibility of regression/unit > tests > - pointer to associated webrev > - list of approvals > - contributor acknowledgements > > Though we expect most changesets to contain updates for a single bug, > our convention should easily accommodate changesets involving multiple > bugs. Based on informal discussions, here's a potential format: > > The number of lines in the changeset is equal to the number of bugs. > For each bug, there is a line of the following form: > > : [*] > > where > > - a 7-digit bugid allocated by the Sun bug database > - the complete synposis for the bugid > * - a comma separated list of reviewers of the change > (repository userid) > > The name of the person submitting the change is the user who created > the changeset. > > For example: > > 4853841: Nervous text demo displays wrong version [iris, duke] > > This covers the common information but is that sufficient? I think > that the optional information regarding testing, webrev, and approvals > should be contained in the bug, but what about contributor > acknowledgements? Perhaps something along these lines is more > suitable: > > For each bug there is a block of the following form: > > : > Review: * > Credit: * > > where > > , , > - described above > > - arbitrary string of contributor acknowledgments > > The first two lines are required. The third is optional. The name > of the person submitting the change is user who created the > changeset. > > For example: > > 4853841: Nervous text demo displays wrong version > Review: iris, duke > Credit: mr - for extending the demo to accept arguments > > I favor the compactness of the first format; but the second is more > extensible and gives us a simple means to recognise key contributions > besides simple authorship or review. > > What do you think? > > Thanks, > iris > > [1] http://hg.openjdk.java.net From mr at sun.com Fri Nov 9 16:47:01 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 09 Nov 2007 08:47:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: yuri.nesterenko@sun.com; Fri, 09 Nov 2007 14:28:54 +0300; <20071109112854.GC30903@frigate.russia.sun.com> Message-ID: <20071109164701.CAE4726CA08@eggemoggin.niobe.net> > Date: Fri, 09 Nov 2007 14:28:54 +0300 > From: yuri.nesterenko at sun.com > Should there be a convention for the name of author? > A person should be easily found by the name. > > I'm asking that because the name will be written in developer's > .hgrc file and [another name or nick] used for push. > No sense for me to put there 'yuri' as in my OpenJDK public keys collection: > it's too common a name in our part of the world. The current thinking is that anyone who has authorship rights will have a username in the OpenJDK web infrastructure. That's the name that you'll set in your .hgrc so that it appears in the author field of changesets that you create, and it'll also be the name you use to push changesets via ssh. So while "yuri" may be common in your part of the world, within the OpenJDK world it can be yours if you claim it first. Most people will find it most convenient to use their regular Unix username, assuming it isn't already taken. (Note to Sun employees: Borgified usernames of the form xy12345 will, per internal policy, not be permitted.) > E-mail? Will it be obfuscated? The only people we need to identify by their e-mail addresses are contributors who don't yet have authorship rights. Is it worth obfuscating those in the changeset comments themselves? Any technique we use will be obvious to anyone who's so desperate for e-mail addresses that they're willing to clone an hg tree. I'd be inclined to use actual addresses in changeset comments but obfuscate them in the web interface. Or we could identify such contributors only by their full names, but then it'd be hard to find them. > At least a gatekeeper should be able to > quickly find the submitter without research. People who have authorship rights will be able to look up the e-mail address of anyone else who has such rights. - Mark From mr at sun.com Fri Nov 9 17:55:41 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 09 Nov 2007 09:55:41 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: andreas.sterbenz@sun.com; Thu, 08 Nov 2007 17:12:08 PST; <4733B3E8.6050801@sun.com> Message-ID: <20071109175541.E761F26CA08@eggemoggin.niobe.net> > Date: Thu, 08 Nov 2007 17:12:08 -0800 > From: andreas.sterbenz at sun.com > Mark Reinhold wrote: >> No. Authorship information should go with the code. > > Exactly because that information is important it should be stored in the > bug database, where all other information about the bug is stored [*], the > location of which is well known to everyone and not just the developers > working on the JDK, Why does anyone who doesn't know how to navigate the Mercurial web interface need to find this information? In what sense is the location of the bug database better known than that of the Mercurial repositories? > which can be queried using a web interface, etc. We have a web interface for Mercurial, and it's extensible. > Capturing everything in the bug database except code reviewers does not > seem like a good idea to me. The logical conclusion of this line of reasoning is that a changeset shouldn't even carry an author name or a bug number or a comment; we should just put the changeset hash into the relevant bug-database records. That seems wrong. > It is probably a bit more difficult to ensure that the correct information > is in the bug database than to validate the changeset comments, but it > should be possible for the hooks to query it and verify that the relevant > information is present (e.g. must have a comment that includes the text > "Reviewed-by: X"). Possible, yes, but hardly convenient. This approach would make it impossible to validate (prospective) changesets in a local repository when you're not online. - Mark From iris.clark at sun.com Fri Nov 9 18:07:25 2007 From: iris.clark at sun.com (iris.clark at sun.com) Date: Fri, 9 Nov 2007 10:07:25 -0800 (PST) Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <4731527C.6070800@sun.com> (message from David Holmes - Sun Microsystems on Wed, 07 Nov 2007 15:51:56 +1000) Message-ID: <200711091807.lA9I7PR3026190@ribbit.SFBay.Sun.COM> Hi, David. > Are you suggesting that once the cause of a bug is determined then the > synopsis should be changed to reflect that? I've updated a few "bad" > synopses in my time too, but not generally to the extent of changing > them from being failure oriented to being cause oriented. As the initial evaluator of several java subcategories I regularly update a bug's synopsis. The key condition is that a user encountering the problem should be able to find the bug based upon the most obvious symptom; for an RFE, the synopsis should describe the desired end result. A series of bugs that have the same cause will probably be marked as duplicates or "see also" bugs, so it is not necessary to encode this information in the synopsis. Details describing the cause of the bug, approach for the solution, and other technical details belong in the bug's evaluation. I don't believe that these technical details belong in the changeset comments because we expect them to often be extensive. I think the bug's evaluation is a more suitable location. iris From iris.clark at Sun.COM Fri Nov 9 18:12:19 2007 From: iris.clark at Sun.COM (Iris Clark) Date: Fri, 9 Nov 2007 10:12:19 -0800 (PST) Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47301AA1.9090600@sun.com> (message from Andreas Sterbenz on Mon, 05 Nov 2007 23:41:21 -0800) Message-ID: <200711091812.lA9ICJ4R026196@ribbit.SFBay.Sun.COM> Hi. > Because we don't have a publicly writable bug database, I assume that the > process for non-Sun committers will have to be that they ask a Sun person > to update the bug for them anyway to fill in the evaluation. In other > words, the committer will send the evaluation, along with any additional > information, via email to a Sun employee who will then put it into the bug > database. So I don't think we need to stick it into the changeset comment. I agree with Andreas. The reason for asking the submitter to provide evaluation content even though they can not edit the bug directly (at least for now) is to preserve the consistency of where information goes over time. You don't want to hunt around in different locations depending on when the bug was addressed. We already have this problem and it can make getting up to speed in a new area difficult. iris From iris.clark at Sun.COM Fri Nov 9 18:39:40 2007 From: iris.clark at Sun.COM (Iris Clark) Date: Fri, 9 Nov 2007 10:39:40 -0800 (PST) Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071108182513.17B6878086@eggemoggin.niobe.net> (message from Mark Reinhold on Thu, 08 Nov 2007 10:25:13 -0800) Message-ID: <200711091839.lA9IdeMY026245@ribbit.SFBay.Sun.COM> Hi, Mark. > The goal here > isn't to give credit to every last person who helped with the change, but > rather to acknowledge non-committers who contribute whole changes. I'd > rather see just a simple acknowledgment listing the contributor's e-mail > address, e.g., > > Contributed-by: Random Hacker > > We can change "Review:" to "Reviewed-by:" as well, to stress the analogy > with RFC-822 and the fact that changeset comments aren't intended to be > arbitrary text. How can we be sure that Random Hacker doesn't have a problem with us releasing his e-mail address? If somebody is commiting a change, then they've already agreed to the SCA. I'm not sure if signing the SCA means that we can use their e-mail address, but I think we can assume that by choosing to contribute to an open project, certain information is public. On the other hand, I don't know if the same can be said for proxy submissions although I believe it can be since we won't accept proxy submissions without the original author signing the SCA. Do we have absolute clarity on the policy here? iris From David.Herron at Sun.COM Fri Nov 9 19:18:19 2007 From: David.Herron at Sun.COM (David Herron) Date: Fri, 09 Nov 2007 11:18:19 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711091839.lA9IdeMY026245@ribbit.SFBay.Sun.COM> References: <200711091839.lA9IdeMY026245@ribbit.SFBay.Sun.COM> Message-ID: <4734B27B.6090309@sun.com> Iris Clark wrote: > Hi, Mark. > > >> The goal here >> isn't to give credit to every last person who helped with the change, but >> rather to acknowledge non-committers who contribute whole changes. I'd >> rather see just a simple acknowledgment listing the contributor's e-mail >> address, e.g., >> >> Contributed-by: Random Hacker >> >> We can change "Review:" to "Reviewed-by:" as well, to stress the analogy >> with RFC-822 and the fact that changeset comments aren't intended to be >> arbitrary text. >> > > How can we be sure that Random Hacker doesn't have a problem with us > releasing his e-mail address? > > If somebody is commiting a change, then they've already agreed to the > SCA. I'm not sure if signing the SCA means that we can use their > e-mail address, but I think we can assume that by choosing to > contribute to an open project, certain information is public. On the > other hand, I don't know if the same can be said for proxy submissions > although I believe it can be since we won't accept proxy submissions > without the original author signing the SCA. Do we have absolute > clarity on the policy here? > > iris > Right, I just reread the SCA and it only talks about joint ownership assignment, and not any statement about names and email addresses being published. That would fall under privacy considerations. e.g. Sun's corporate Privacy Policy. - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Sterbenz at Sun.COM Fri Nov 9 19:33:39 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Fri, 09 Nov 2007 11:33:39 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071109175541.E761F26CA08@eggemoggin.niobe.net> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> Message-ID: <4734B613.7020406@sun.com> Mark Reinhold wrote: >> Date: Thu, 08 Nov 2007 17:12:08 -0800 >> From: andreas.sterbenz at sun.com > >> Mark Reinhold wrote: >>> No. Authorship information should go with the code. >> Exactly because that information is important it should be stored in the >> bug database, where all other information about the bug is stored [*], the >> location of which is well known to everyone and not just the developers >> working on the JDK, > > Why does anyone who doesn't know how to navigate the Mercurial web > interface need to find this information? > > In what sense is the location of the bug database better known than that > of the Mercurial repositories? Just thinking of Sun employees for now: management, support and services people, developers for other products that use the JDK, e.g. App Server or Access Manager. Any of them may need to get in touch with the code reviewers in case the primary author of the fix is unavailable. All of them know where to find the bug database but probably won't know the magic URL for the correct JDK repository. >> Capturing everything in the bug database except code reviewers does not >> seem like a good idea to me. > > The logical conclusion of this line of reasoning is that a changeset > shouldn't even carry an author name or a bug number or a comment; we > should just put the changeset hash into the relevant bug-database > records. > > That seems wrong. There is clearly some information that should be in the changeset comments because that can make life more efficient for us JDK developers when we crawl around in the repository. Primary author, bug number, and synopsis - as we have in the SCCS comments today - seems sufficient to me. As long as I can find everything else in the bug database, if I need it. Anyway, the main issue is that there is a lot of value in having all relevant information about a bug stored in ONE central place, which is the bug database. If you feel differently, then we'll have to agree to disagree. Andreas. From neal at gafter.com Fri Nov 9 19:58:16 2007 From: neal at gafter.com (Neal Gafter) Date: Fri, 9 Nov 2007 11:58:16 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <4734B613.7020406@sun.com> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> <4734B613.7020406@sun.com> Message-ID: <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> On Nov 9, 2007 11:33 AM, Andreas Sterbenz wrote: > > In what sense is the location of the bug database better known than that > > of the Mercurial repositories? > > Just thinking of Sun employees for now: management, support and services > people, developers for other products that use the JDK, e.g. App Server or > Access Manager. > > Any of them may need to get in touch with the code reviewers in case the > primary author of the fix is unavailable. All of them know where to find > the bug database but probably won't know the magic URL for the correct JDK > repository. > > There is clearly some information that should be in the changeset comments > because that can make life more efficient for us JDK developers when we > crawl around in the repository. Primary author, bug number, and synopsis - > as we have in the SCCS comments today - seems sufficient to me. As long as > I can find everything else in the bug database, if I need it. Perhaps Sun's internal tools need to be modified so they can pull some information out of the change sets. Anyway, the main issue is that there is a lot of value in having all > relevant information about a bug stored in ONE central place, which is the > bug database. If you feel differently, then we'll have to agree to > disagree. If the result is a situation that is convenient for you at the expense of inconvenience for outside openjdk developers, agreeing to disagree isn't a very palatable solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Sterbenz at Sun.COM Fri Nov 9 20:15:44 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Fri, 09 Nov 2007 12:15:44 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> <4734B613.7020406@sun.com> <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> Message-ID: <4734BFF0.2010708@sun.com> Neal Gafter wrote: > > Anyway, the main issue is that there is a lot of value in having all > relevant information about a bug stored in ONE central place, which > is the > bug database. If you feel differently, then we'll have to agree to > disagree. > > If the result is a situation that is convenient for you at the expense > of inconvenience for outside openjdk developers, agreeing to disagree > isn't a very palatable solution. The only thing we are talking about here is whether the changeset comments should include the names of the code reviewers. Are you saying it would be an inconvenience for non-Sun developers if they don't? It is obvious that the current situation with the bug database is unacceptable, but a solution is already planned (http://blogs.sun.com/mr/entry/under_construction). Having easy access to the names of the code reviewers seems to be the least problem to me. Andreas. From neal at gafter.com Fri Nov 9 20:50:20 2007 From: neal at gafter.com (Neal Gafter) Date: Fri, 9 Nov 2007 12:50:20 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <4734BFF0.2010708@sun.com> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> <4734B613.7020406@sun.com> <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> <4734BFF0.2010708@sun.com> Message-ID: <15e8b9d20711091250k4d7285f3y9a4b8c9d4bbb3966@mail.gmail.com> On Nov 9, 2007 12:15 PM, Andreas Sterbenz wrote: > Neal Gafter wrote: > > > > Anyway, the main issue is that there is a lot of value in having all > > relevant information about a bug stored in ONE central place, which > > is the > > bug database. If you feel differently, then we'll have to agree to > > disagree. > > > > If the result is a situation that is convenient for you at the expense > > of inconvenience for outside openjdk developers, agreeing to disagree > > isn't a very palatable solution. > > The only thing we are talking about here is whether the changeset comments > should include the names of the code reviewers. Are you saying it would be > an inconvenience for non-Sun developers if they don't? My mistake; I didn't realize "all relevant information" meant the names of code reviewers. Two advantage of having code reviewers named in the changeset are (1) reviewers would get well-deserved developer community Karma for reviewing changes, and (2) Software archaeologists would have more information about who they might need to consult to resolve future issues with the code. But I agree this isn't as important as other information that does belong in the changeset comments, such as an explanation of the strategy for the change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Fri Nov 9 20:52:04 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 09 Nov 2007 12:52:04 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: andreas.sterbenz@sun.com; Fri, 09 Nov 2007 11:33:39 PST; <4734B613.7020406@sun.com> Message-ID: <20071109205204.62F2A26CA08@eggemoggin.niobe.net> > Date: Fri, 09 Nov 2007 11:33:39 -0800 > From: andreas.sterbenz at sun.com > Mark Reinhold wrote: >> Why does anyone who doesn't know how to navigate the Mercurial web >> interface need to find this information? >> >> In what sense is the location of the bug database better known than that >> of the Mercurial repositories? > > Just thinking of Sun employees for now: management, support and services > people, developers for other products that use the JDK, e.g. App Server or > Access Manager. We need to think of a wider set of people than those who work for Sun. > Any of them may need to get in touch with the code reviewers in case the > primary author of the fix is unavailable. All of them know where to find > the bug database but probably won't know the magic URL for the correct JDK > repository. We're already planning to put changeset pointers into bug reports, automatically. So I don't think this is really much of an issue. > ... > > Anyway, the main issue is that there is a lot of value in having all > relevant information about a bug stored in ONE central place, which is the > bug database. If you feel differently, then we'll have to agree to disagree. Perhaps so. There's an important non-technical aspect of this issue that hasn't really been discussed here: Giving credit where credit is due. Reviewing code -- or at least doing it well -- is hard work. If I were a non-Sun OpenJDK contributor then I think I'd prefer to receive credit for having done a code review in the form of having my name in the changeset comment rather than listed somewhere in a bug database. The changeset comment will travel with the code, wherever it goes. Many people will see the code but rarely, if ever, look at the bug database, which exists in just one place. The names of non-author contributors also belong in changeset comments, for the same reason. It'd be interesting to hear some non-Sun perspectives on this. - Mark From Jim.A.Graham at Sun.COM Fri Nov 9 21:01:41 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Fri, 09 Nov 2007 13:01:41 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <4734BFF0.2010708@sun.com> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> <4734B613.7020406@sun.com> <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> <4734BFF0.2010708@sun.com> Message-ID: <0JR900029BQURRB0@fe-sfbay-09.sun.com> Why not both? Why does it have to be one *or* the other? I really don't get that aspect of these discussions. The somewhat vague argument that information in the changesets could become stale is only mildly interesting. For one thing, that may happen - what? - once a year or so? If it happens more than that, then we need to examine our development documentation processes. Second, even if it happens, exactly what problem might it cause that is so irreversible that the project will be irreparably harmed? Finally, it should be common knowledge that the information that exists there should not be taken as the authoritative answer, just a convenient copy of the authoritative answer for purposes of browsing. The vague idea that such duplication of information *might* be wrong and that this error could somehow cause serious repercussions has to be weighed against the value of the convenience of not having to correlate several repositories of information just to understand the changes that are occurring. How exactly has this fear of potentially inaccurate information taken over and pushed out all other considerations? It's not like the information included in either location is somehow legally binding - it's all there just to help us get work done... ...jim Andreas Sterbenz wrote: > Neal Gafter wrote: >> >> Anyway, the main issue is that there is a lot of value in having all >> relevant information about a bug stored in ONE central place, which >> is the >> bug database. If you feel differently, then we'll have to agree to >> disagree. >> If the result is a situation that is convenient for you at the expense >> of inconvenience for outside openjdk developers, agreeing to disagree >> isn't a very palatable solution. > > The only thing we are talking about here is whether the changeset > comments should include the names of the code reviewers. Are you saying > it would be an inconvenience for non-Sun developers if they don't? > > It is obvious that the current situation with the bug database is > unacceptable, but a solution is already planned > (http://blogs.sun.com/mr/entry/under_construction). Having easy access > to the names of the code reviewers seems to be the least problem to me. > > Andreas. From landonf at threerings.net Mon Nov 12 20:15:12 2007 From: landonf at threerings.net (Landon Fuller) Date: Mon, 12 Nov 2007 12:15:12 -0800 Subject: Porting: Mac OS X Leopard (and Tiger) In-Reply-To: <5EB35440-916B-4319-BCFF-002ADFE1547A@threerings.net> References: <17F34593-B7B4-4144-9EE2-82C9165A7F9B@threerings.net> <472F7546.7060102@Sun.COM> <539369E8-DB84-4523-91B4-4406534CF7DD@threerings.net> <20071105210831.GA96588@misty.eyesbeyond.com> <5EB35440-916B-4319-BCFF-002ADFE1547A@threerings.net> Message-ID: <1FD6E3BD-1ACF-4C71-904F-196223588FD5@threerings.net> Howdy, I just thought I'd send a small status update: - I've got hotspot running on Mac OS 10.4 (Tiger) and 10.5 (Leopard). - Both i386 (10.4 & 10.5) and amd64 (10.5 Core 2 Duo Macs) are supported. - Swing works (x11) - Hotspot c1/c2 mostly work - -Xint interprer mode appears to run without errors. There are, of course, still some significant bugs, and I'm continuing to work on hotspot Darwin i386 ABI stack alignment issues. I've also submitted my Sun Contributor Agreement, in the hope that these changes can eventually move forward to OpenJDK. I've posted the latest status update here: http://landonf.bikemonkey.org/code/macosx/ FreeBSD_Java_16_Status_Update.20071112.html Cheers, Landon Fuller -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jesse.glick at sun.com Tue Nov 13 00:10:04 2007 From: jesse.glick at sun.com (Jesse Glick) Date: Mon, 12 Nov 2007 19:10:04 -0500 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071109205204.62F2A26CA08@eggemoggin.niobe.net> References: <4734B613.7020406@sun.com> <20071109205204.62F2A26CA08@eggemoggin.niobe.net> Message-ID: Mark Reinhold wrote: > There's an important non-technical aspect of this issue that hasn't > really been discussed here: Giving credit where credit is due. This is fine, but a CREDITS file can do the same job, probably more visibly. I think this discussion is diverging from the basic question of why you would want to look at changeset comments at all. For me, there are two essential parts of a changeset comment: 1. What was changed and why, in case you want to know if the changeset is relevant to you. 2. More information, in case you have decided that the changeset probably is relevant to you. For the second part, a bug number is enough; you can look up everything else there. For the first part, the text should be kept short, and should include only information necessary for a reader to decide whether they want to investigate the change. Key information: 1a. The visible symptom of the problem being fixed, in case the reader is experiencing the same or similar problem, perhaps in an earlier release, and wants to know if and when a fix was attempted. 1b. A summary of the changes being made to the code, in case the reader suspects that a recent coding error caused a regression and wants to track down the responsible commit. Example: "#1234567: selecting a combo box threw NPE. Fixed by partial rewrite of focus handling code in JComboBox." Short and sweet. If (1a) I have encountered a NPE that I think is related to combo box implementation code, I will see this and immediately look up bug #1234567 and investigate further. Or, if (1b) I am having problems with focus on JComboBox's in recent builds, I will also see this and know to examine the diff to look for problematic code. You may also be watching all commits in Swing code and have a special interest in focus handling or JComboBox.java, in which case both (1a) and (1b) might be useful as filters so you can decide which diffs to inspect closely. An email or RSS notification of the change could easily link to (or attach!) a web summary of the bug report, too. In some cases the fix follows directly from the symptom and hardly needs special mention, e.g. "#1234567: typo in javaws splash screen." where the fix is simply to edit the message. It is certainly important to have recorded somewhere who reviewed a proposed change, in case you are investigating effects of that change later and need to contact them. But I cannot think of a situation where I would be scanning the changelog of a software tree looking for changes reviewed by a particular person! This would just be noise. The same goes for details on how to reproduce the problem, a description of how the fix was verified, workarounds, alternative approaches that were suggested, etc. - these can all be found in the bug database. -Jesse -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net http://google.com/search?q=e%5E%28pi*i%29%2B1 From aph at redhat.com Tue Nov 13 11:14:50 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Nov 2007 11:14:50 +0000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <0JR900029BQURRB0@fe-sfbay-09.sun.com> References: <20071109175541.E761F26CA08@eggemoggin.niobe.net> <4734B613.7020406@sun.com> <15e8b9d20711091158l4a6308ebrb48a1824cb89c637@mail.gmail.com> <4734BFF0.2010708@sun.com> <0JR900029BQURRB0@fe-sfbay-09.sun.com> Message-ID: <18233.34602.919854.430981@zebedee.pink> Jim Graham writes: > Why not both? Why does it have to be one *or* the other? I really > don't get that aspect of these discussions. > > The somewhat vague argument that information in the changesets > could become stale is only mildly interesting. For one thing, that > may happen - what? - once a year or so? If it happens more than > that, then we need to examine our development documentation > processes. Second, even if it happens, exactly what problem might > it cause that is so irreversible that the project will be > irreparably harmed? Finally, it should be common knowledge that > the information that exists there should not be taken as the > authoritative answer, just a convenient copy of the authoritative > answer for purposes of browsing. > > The vague idea that such duplication of information *might* be > wrong and that this error could somehow cause serious repercussions > has to be weighed against the value of the convenience of not > having to correlate several repositories of information just to > understand the changes that are occurring. How exactly has this > fear of potentially inaccurate information taken over and pushed > out all other considerations? > > It's not like the information included in either location is > somehow legally binding - it's all there just to help us get work > done... Precisely. As someone outside Sun, I agree wholeheartedly with this. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Tue Nov 13 11:26:51 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Nov 2007 11:26:51 +0000 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <200711091839.lA9IdeMY026245@ribbit.SFBay.Sun.COM> References: <20071108182513.17B6878086@eggemoggin.niobe.net> <200711091839.lA9IdeMY026245@ribbit.SFBay.Sun.COM> Message-ID: <18233.35323.90835.227310@zebedee.pink> Iris Garcia writes: > > > The goal here isn't to give credit to every last person who > > helped with the change, but rather to acknowledge non-committers > > who contribute whole changes. I'd rather see just a simple > > acknowledgment listing the contributor's e-mail address, e.g., > > > > Contributed-by: Random Hacker > > > > We can change "Review:" to "Reviewed-by:" as well, to stress the > > analogy with RFC-822 and the fact that changeset comments aren't > > intended to be arbitrary text. > > How can we be sure that Random Hacker doesn't have a problem with > us releasing his e-mail address? > > If somebody is commiting a change, then they've already agreed to > the SCA. I'm not sure if signing the SCA means that we can use > their e-mail address, but I think we can assume that by choosing to > contribute to an open project, certain information is public. Anyone who contributes any code to a free software project must make their email address available so that they can be contacted by anyone reviewing their proposed change. The set of reviewers is not limited to those with the power to accept a change, but includes anyone who is capable of reading one. 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 Tue Nov 13 20:26:23 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 13 Nov 2007 21:26:23 +0100 Subject: Happy Liberation Day Message-ID: <1194985583.3021.73.camel@dijkstra.wildebeest.org> Hi, Seems it that Freedom/Libre/Liberation day only lives on some webpages currently. So let me be the first on the list to say happy November 13th! There have been several posts about this already on the various blogs: http://blogs.sun.com/rsands/entry/november_13_is_java_liberation http://gnu.wildebeest.org/diary/2007/11/13/one-year-ago-java-liberation-day/ http://weblogs.java.net/blog/terrencebarr/archive/2007/11/happy_birthday.html http://blogs.sun.com/tmarble/entry/the_java_experience http://weblogs.java.net/blog/robogeek/archive/2007/11/java_freedom_da.html http://www.jroller.com/neugens/entry/happy_birthday1 Happy birthday everybody. I am sure next year will be even more fun! Cheers, Mark From robilad at kaffe.org Tue Nov 13 21:02:21 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 13 Nov 2007 22:02:21 +0100 Subject: New Group Proposal: OpenJDK Porters Message-ID: <473A10DD.2060001@kaffe.org> Dear OpenJDK developers, I'd like to propose creation of the OpenJDK Porters Group. The intent of this group is to discuss porting of OpenJDK to different platforms, and support projects undertaking such efforts. It will help to integrate different porting projects into OpenJDK. Topics for discussion include: - Ports to new architectures - Ports to new operating systems - Collaboration with other OpenJDK porting projects This group will have one mailing list. It is open to everyone. The initial members of this group are David Herron, Tom Marble, Mark Reinhold, and Dalibor Topic (moderator). cheers, dalibor topic From listas at enelserver.com Tue Nov 13 21:44:39 2007 From: listas at enelserver.com (Leonel Nunez) Date: Tue, 13 Nov 2007 14:44:39 -0700 (MST) Subject: irc channel Message-ID: <41338.189.155.240.226.1194990279.squirrel@enelserver.com> hello Is there a IRC channel for icedtea ?? thank you leonel From langel at redhat.com Tue Nov 13 21:44:36 2007 From: langel at redhat.com (Lillian Angel) Date: Tue, 13 Nov 2007 16:44:36 -0500 Subject: irc channel In-Reply-To: <41338.189.155.240.226.1194990279.squirrel@enelserver.com> References: <41338.189.155.240.226.1194990279.squirrel@enelserver.com> Message-ID: <473A1AC4.9060601@redhat.com> You can use #classpath(Freenode) or #openjdk to ask questions about IcedTea The mailing list is distro-pkg-dev at openjdk.java.net Lillian Leonel Nunez wrote: > hello > > Is there a IRC channel for icedtea ?? > > > thank you > > leonel > From robilad at kaffe.org Tue Nov 13 21:50:42 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Tue, 13 Nov 2007 22:50:42 +0100 Subject: irc channel In-Reply-To: <41338.189.155.240.226.1194990279.squirrel@enelserver.com> References: <41338.189.155.240.226.1194990279.squirrel@enelserver.com> Message-ID: <473A1C32.1010306@kaffe.org> Leonel Nunez wrote: > hello > > Is there a IRC channel for icedtea ?? We're using #openjdk for pretty much everything currently. cheers, dalibor topic From mr at sun.com Tue Nov 13 22:27:50 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 13 Nov 2007 14:27:50 -0800 Subject: New Group Proposal: OpenJDK Porters In-Reply-To: robilad@kaffe.org; Tue, 13 Nov 2007 22:02:21 +0100; <473A10DD.2060001@kaffe.org> Message-ID: <20071113222750.6239326CA91@eggemoggin.niobe.net> > Date: Tue, 13 Nov 2007 22:02:21 +0100 > From: Dalibor Topic > I'd like to propose creation of the OpenJDK Porters Group. The > intent of this group is to discuss porting of OpenJDK to different > platforms, and support projects undertaking such efforts. ... I hereby second this fine proposal! - Mark From David.Herron at Sun.COM Tue Nov 13 22:58:08 2007 From: David.Herron at Sun.COM (David Herron) Date: Tue, 13 Nov 2007 14:58:08 -0800 Subject: New Group Proposal: OpenJDK Porters In-Reply-To: <20071113222750.6239326CA91@eggemoggin.niobe.net> References: <20071113222750.6239326CA91@eggemoggin.niobe.net> Message-ID: <473A2C00.8010109@sun.com> Mark Reinhold wrote: >> Date: Tue, 13 Nov 2007 22:02:21 +0100 >> From: Dalibor Topic >> > > >> I'd like to propose creation of the OpenJDK Porters Group. The >> intent of this group is to discuss porting of OpenJDK to different >> platforms, and support projects undertaking such efforts. ... >> > > I hereby second this fine proposal! > > - Mark > ditto -------------- next part -------------- An HTML attachment was scrubbed... URL: From robilad at kaffe.org Tue Nov 13 23:53:22 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 14 Nov 2007 00:53:22 +0100 Subject: New Group Proposal: OpenJDK Porters In-Reply-To: <473A2C00.8010109@sun.com> References: <20071113222750.6239326CA91@eggemoggin.niobe.net> <473A2C00.8010109@sun.com> Message-ID: <473A38F2.9040504@kaffe.org> David Herron wrote: > Mark Reinhold wrote: >>> Date: Tue, 13 Nov 2007 22:02:21 +0100 >>> From: Dalibor Topic >>> >> >> >>> I'd like to propose creation of the OpenJDK Porters Group. The >>> intent of this group is to discuss porting of OpenJDK to different >>> platforms, and support projects undertaking such efforts. ... >>> >> >> I hereby second this fine proposal! >> >> - Mark >> > ditto > Thank you for your support, and happy liberation day! cheers, dalibor topic From robilad at kaffe.org Wed Nov 14 00:49:59 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 14 Nov 2007 01:49:59 +0100 Subject: Happy Liberation Day In-Reply-To: <1194985583.3021.73.camel@dijkstra.wildebeest.org> References: <1194985583.3021.73.camel@dijkstra.wildebeest.org> Message-ID: <473A4637.5090001@kaffe.org> Mark Wielaard wrote: > Hi, > > Seems it that Freedom/Libre/Liberation day only lives on some webpages > currently. So let me be the first on the list to say happy November > 13th! There have been several posts about this already on the various > blogs: > > http://blogs.sun.com/rsands/entry/november_13_is_java_liberation > http://gnu.wildebeest.org/diary/2007/11/13/one-year-ago-java-liberation-day/ > http://weblogs.java.net/blog/terrencebarr/archive/2007/11/happy_birthday.html > http://blogs.sun.com/tmarble/entry/the_java_experience > http://weblogs.java.net/blog/robogeek/archive/2007/11/java_freedom_da.html > http://www.jroller.com/neugens/entry/happy_birthday1 > > Happy birthday everybody. I am sure next year will be even more fun! > http://robilad.livejournal.com/22969.html and http://robilad.livejournal.com/22731.html , too. Thanks for a great year, everyone, and keep up the good work. I am looking forward to another great FOSDEM. ;) cheers, dalibor topic From Tom.Marble at Sun.COM Wed Nov 14 05:28:41 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Tue, 13 Nov 2007 23:28:41 -0600 Subject: New Group Proposal: OpenJDK Porters In-Reply-To: <20071113222750.6239326CA91@eggemoggin.niobe.net> References: <20071113222750.6239326CA91@eggemoggin.niobe.net> Message-ID: <473A8789.90507@sun.com> Mark Reinhold wrote: >> Date: Tue, 13 Nov 2007 22:02:21 +0100 >> From: Dalibor Topic > >> I'd like to propose creation of the OpenJDK Porters Group. The >> intent of this group is to discuss porting of OpenJDK to different >> platforms, and support projects undertaking such efforts. ... > > I hereby second this fine proposal! I enthusiastically endorse this proposal. Supporting OpenJDK porting directly advances our goal of expanding platform ubiquity. Sincerely, --Tom From mark at klomp.org Wed Nov 14 09:29:24 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 14 Nov 2007 10:29:24 +0100 Subject: Happy Liberation Day In-Reply-To: <1194985583.3021.73.camel@dijkstra.wildebeest.org> References: <1194985583.3021.73.camel@dijkstra.wildebeest.org> Message-ID: <1195032564.3027.7.camel@dijkstra.wildebeest.org> On Tue, 2007-11-13 at 21:26 +0100, Mark Wielaard wrote: > Seems it that Freedom/Libre/Liberation day only lives on some webpages > currently. So let me be the first on the list to say happy November > 13th! There have been several posts about this already on the various > blogs: And there are even videos posted (in evil proprietary flash and good free ogg/theora - isn't it nice if the world is just black and white) of Mark Reinhold, Ray Gans & John Mulner on this historic day at "The Official Site for Breaking News and the Latest Information from Sun": http://blogs.sun.com/ontherecord/entry/happy_anniversary_for_open_source From mr at sun.com Fri Nov 16 04:44:08 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 15 Nov 2007 20:44:08 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: gnu_andrew@member.fsf.org; Fri, 09 Nov 2007 09:58:29 GMT; <17c6771e0711090158n1def305y911b78cb1c117d11@mail.gmail.com> Message-ID: <20071116044408.3B82BC13@callebaut.niobe.net> > Date: Fri, 09 Nov 2007 09:58:29 +0000 > From: Andrew John Hughes > On 09/11/2007, roman.kennke at aicas.com wrote: >> ... >> >> What about 'classlibs' for the class libs, rather than jdk? > > classlibs seems a better name, I think 'jdk' is a legacy name from before > langtools and friends were split out (but then again, this never included > hotspot). (Historical note: Many years ago it did include the Classic VM, the original C-language bytecode interpreter.) The corba and jaxp and jaxws and langtools subtrees all contain class libraries too, so "classlibs" is little better than "jdk" (which used to be "j2se", which was even worse). - Mark From mr at sun.com Fri Nov 16 04:54:36 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 15 Nov 2007 20:54:36 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: mr@sun.com; Thu, 08 Nov 2007 11:30:05 PST; <20071108193005.E301978089@eggemoggin.niobe.net> Message-ID: <20071116045436.A63D7C13@callebaut.niobe.net> The consensus amongst existing contributors was in favor of renaming the MASTER forests as proposed, so I've gone and done that. Effective immediately please replace all URLs of the form http://hg.openjdk.java.net/jdk7/MASTER with http://hg.openjdk.java.net/jdk7/jdk7 , and similarly replace "MASTER-GATE" with "jdk7-gate". - Mark From gnu_andrew at member.fsf.org Fri Nov 16 11:31:10 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 16 Nov 2007 11:31:10 +0000 Subject: Should we rename the MASTER forest? In-Reply-To: <20071116044408.3B82BC13@callebaut.niobe.net> References: <17c6771e0711090158n1def305y911b78cb1c117d11@mail.gmail.com> <20071116044408.3B82BC13@callebaut.niobe.net> Message-ID: <17c6771e0711160331p54499d25o67ab7b60771b8714@mail.gmail.com> On 16/11/2007, Mark Reinhold wrote: > > > Date: Fri, 09 Nov 2007 09:58:29 +0000 > > From: Andrew John Hughes > > > On 09/11/2007, roman.kennke at aicas.com wrote: > >> ... > >> > >> What about 'classlibs' for the class libs, rather than jdk? > > > > classlibs seems a better name, I think 'jdk' is a legacy name from > before > > langtools and friends were split out (but then again, this never > included > > hotspot). > > (Historical note: Many years ago it did include the Classic VM, the > original C-language bytecode interpreter.) > > The corba and jaxp and jaxws and langtools subtrees all contain class > libraries too, so "classlibs" is little better than "jdk" (which used > to be "j2se", which was even worse). > > - Mark > Yeah, I thought that after posting... Thinking more philosophically, I think the whole 'main branch is jdk7' simply comes down to a release-oriented approach within proprietary software in general, as opposed to the FOSS approach where releases are more offshots of the main development tree, with current development always retaining central focus. After all, there is no need for a release in order to get hold of the code! -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Fri Nov 16 16:53:51 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 16 Nov 2007 08:53:51 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: gnu_andrew@member.fsf.org; Fri, 16 Nov 2007 11:31:10 GMT; <17c6771e0711160331p54499d25o67ab7b60771b8714@mail.gmail.com> Message-ID: <20071116165351.DC486272F05@eggemoggin.niobe.net> > Date: Fri, 16 Nov 2007 11:31:10 +0000 > From: Andrew John Hughes > ... > > Thinking more philosophically, I think the whole 'main branch is jdk7' > simply comes down to a release-oriented approach within proprietary software > in general, as opposed to the FOSS approach where releases are more offshots > of the main development tree, with current development always retaining > central focus. After all, there is no need for a release in order to get > hold of the code! Granted, though I'm not sure I'd agree that the release-oriented approach is specific to proprietary software. It's a general technique that works well to focus the attention of a large, distributed team on a specific engineering goal, though it's by no means the only way to do so. At any rate, as Roman pointed out, a distributed SCM like Mercurial tends to blur the difference between the two approaches, as far as the code is concerned. - Mark From Kelly.Ohair at Sun.COM Fri Nov 16 17:38:36 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 16 Nov 2007 09:38:36 -0800 Subject: Should we rename the MASTER forest? In-Reply-To: <20071116044408.3B82BC13@callebaut.niobe.net> References: <20071116044408.3B82BC13@callebaut.niobe.net> Message-ID: <473DD59C.7080802@sun.com> The jdk repository (formerly j2se workspace) also includes the full jdk image creation, including construction of rt.jar and tools.jar, and building the demos. Now that langtools is separate and the bulk of the jdk repository build doesn't run itself during the build, it might be possible to look at somehow separating out or isolating the classfile building, the native code building, the image creation, and the demo building (which does run the jdk image). What this means to the naming or layout I'm not sure, but thought I would mention it. -kto Mark Reinhold wrote: >> Date: Fri, 09 Nov 2007 09:58:29 +0000 >> From: Andrew John Hughes > >> On 09/11/2007, roman.kennke at aicas.com wrote: >>> ... >>> >>> What about 'classlibs' for the class libs, rather than jdk? >> classlibs seems a better name, I think 'jdk' is a legacy name from before >> langtools and friends were split out (but then again, this never included >> hotspot). > > (Historical note: Many years ago it did include the Classic VM, the > original C-language bytecode interpreter.) > > The corba and jaxp and jaxws and langtools subtrees all contain class > libraries too, so "classlibs" is little better than "jdk" (which used > to be "j2se", which was even worse). > > - Mark From Weijun.Wang at Sun.COM Mon Nov 19 02:18:25 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Mon, 19 Nov 2007 10:18:25 +0800 Subject: Should we rename the MASTER forest? In-Reply-To: <473DD59C.7080802@sun.com> References: <20071116044408.3B82BC13@callebaut.niobe.net> <473DD59C.7080802@sun.com> Message-ID: <555B44F1-9B20-425D-865F-74ED521DEAA1@sun.com> How about we at least use the capitalized name JDK7 (or JDK) so that it stands out of other workspaces? Max From Tom.Marble at Sun.COM Mon Nov 19 18:29:22 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Mon, 19 Nov 2007 12:29:22 -0600 Subject: Free Java Meeting @ FOSDEM 2008 Message-ID: <4741D602.8080201@sun.com> All: It's time to finalize our proposal for FOSDEM 2008. What was previously known as the "Escape the Java Trap" event and last year we called the "GNU Classpath+OpenJDK DevJam" will this year be the "Free Java Meeting". Each project should have an introduction, but it may make most sense to organize the sessions around topics with cross-project interest (e.g. Virtual Machines, Architectures + Porting, Modularity, Packaging, etc.) Please add/correct/elaborate on the ideas for the Program here: http://wiki.debian.org/Java/DevJam/2008/Fosdem#Program Sponsorship is still to be determined, but it was very useful last year to have everyone that is planning to attend sign up so we have a sense of size/interests, etc. Please sign up now! On Wednesday this week (at the latest) we'll submit the formal proposal for a DevRoom (and then try to define specific time blocks). Thanks! --Tom From Richard.Sands at Sun.COM Tue Nov 20 17:28:43 2007 From: Richard.Sands at Sun.COM (Rich Sands) Date: Tue, 20 Nov 2007 12:28:43 -0500 Subject: Fun pictures from Sun's Java Liberation Day celebration Message-ID: <4743194B.9050708@sun.com> An HTML attachment was scrubbed... URL: From mark at klomp.org Tue Nov 20 18:22:30 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 20 Nov 2007 19:22:30 +0100 Subject: Free Java Meeting @ FOSDEM 2008 In-Reply-To: <4741D602.8080201@sun.com> References: <4741D602.8080201@sun.com> Message-ID: <1195582950.16698.8.camel@dijkstra.wildebeest.org> Hi Tom, On Mon, 2007-11-19 at 12:29 -0600, Tom Marble wrote: > Please add/correct/elaborate on the ideas for the Program here: > http://wiki.debian.org/Java/DevJam/2008/Fosdem#Program > > Sponsorship is still to be determined, but it was very useful > last year to have everyone that is planning to attend sign up > so we have a sense of size/interests, etc. Please sign up now! This sounds great. I would love to come and just added my name to the list officially. For others that might struggle like me, you first have to create an account through http://wiki.debian.org/UserPreferences before you are allowed to edit the page. Cheers, Mark From gnu_andrew at member.fsf.org Thu Nov 22 09:14:02 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 22 Nov 2007 09:14:02 +0000 Subject: Free Java Meeting @ FOSDEM 2008 In-Reply-To: <1195582950.16698.8.camel@dijkstra.wildebeest.org> References: <4741D602.8080201@sun.com> <1195582950.16698.8.camel@dijkstra.wildebeest.org> Message-ID: <17c6771e0711220114g5c90b3f5y5abd73e6a585e773@mail.gmail.com> On 20/11/2007, Mark Wielaard wrote: > > Hi Tom, > > On Mon, 2007-11-19 at 12:29 -0600, Tom Marble wrote: > > Please add/correct/elaborate on the ideas for the Program here: > > http://wiki.debian.org/Java/DevJam/2008/Fosdem#Program > > > > Sponsorship is still to be determined, but it was very useful > > last year to have everyone that is planning to attend sign up > > so we have a sense of size/interests, etc. Please sign up now! > > This sounds great. I would love to come and just added my name to the > list officially. For others that might struggle like me, you first have > to create an account through http://wiki.debian.org/UserPreferences > before you are allowed to edit the page. > > Cheers, > > Mark > > And if you vaguely remember writing your name on the page last year, scratch your head a bit like I did and you'll probably find you already have an account... ;) -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From theBohemian at gmx.net Thu Nov 22 23:15:36 2007 From: theBohemian at gmx.net (Robert Schuster) Date: Fri, 23 Nov 2007 00:15:36 +0100 Subject: Jalimo @ FOSDEM 'Free Java Meeting' Message-ID: <47460D98.9020103@gmx.net> Hi list, hi Tom, I have seen the request to participate with a talk at the 'Free Java Meeting' at FOSDEM'08[0]. I would like to do so and present JaLiMo which is a project which aims to bring a Java(-like) environment to Linux-based Mobile devices (hence the name :) ). Mobile in the sense of mobile phones, PDAs and internet tablets/UMPC. What we mainly do is packaging, building and maintaining the various projects out there: JamVM, Cacao, GNU Classpath,MIDPath, SWT, java-gnome. Other runtimes as Kaffe and of course Hotspot and PhoneME as well as the IcedTea/OpenJDK libraries are planned for the future. Sometimes we develop some extension to make a library better fit into their. E.g. we have patched java-gnome & SWT to have Maemo-style menus (so called hildonization). The currently targeted platforms are the Maemo and OpenMoko platform. Since OpenMoko is a OpenEmbedded-built distribution and we provide build recipes for that, every other distribution can benefit from our work, too. Oh, yes: Everything is free and open-source software. :) Since a picture say more than 1000 words, let us enter screenshot talk: ;) http://www.jalimo.org/wiki/doku.php?id=examples:screenshots http://fsfe.org/en/fellows/robertschuster/images/swt_maemo_2007_11_01 http://fsfe.org/en/fellows/robertschuster/images/midpath_2007_07_09 http://fsfe.org/en/fellows/robertschuster/images/openmoko_2007_08_09 You have probably seen things like that in the past every here and then. Jalimo is about to make that sustainable not just sporadic. What matters for us additionally is that you should not only be able to download the finished binary packages but you should also be able to reproduce them by compiling everything on your own. Further information about the project can be found at our website at jalimo.org. Regards Robert Schuster PS: Jalimo needs volunteers. :) [0] - http://article.gmane.org/gmane.comp.java.openjdk.general/646 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From neugens at limasoftware.net Sun Nov 25 21:13:09 2007 From: neugens at limasoftware.net (Mario Torre) Date: Sun, 25 Nov 2007 22:13:09 +0100 Subject: About bug submission Message-ID: <1196025189.3545.24.camel@nirvana.limasoftware.net> Hello all! I'm writing to try to start a discussion about a problem that I've found while working on IcedTea today. We had a report from a user that filed a new bug on our bugzilla [1]. After a bit of investigation, it was obvious that the bug was an upstream bug, and that was present in at least one version of the jdk itself (I actually tested on 1.6.0.03). Now, I've resubmitted the same bug to the Sun database, but had to copy all the data and the discussion back, as well as the proposed patch, embedding references to our bugzilla directly in the comments. After that, the obvious move would be to close the bug from our side, keeping a reference to upstream; but after all the efforts to search for duplicated bugs, filing a new bug, copying all the data back, etc.. I still don't have a reference id. Now, in this case all this was quite easy, as there were only a couple of comments, but there may be cases where the procedure puts much more efforts on the shoulder of us poor developers that already have days of 36 hours long, and with developers I also mean GNU/Linux distro packagers. I think it would be handy to have some sort of automatic procedure that enable us to keep in sync in such cases, even if we still have to wait up to 3 weeks to have a bug id assigned, but that at least let us not to copy information around. Well, I don't really know what this common procedure could be, but at least some easier way to forward bugs upstream. Both Fedora and Debian for example have bug databases in which they collect user bugs, filter them to see if they are specific for the distribution and if not, forward them. What do you think? Thanks, Mario [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=81 P.S. please, explicitly CC me as for some reason I don't get mails back from the various mailing lists, thank you. -- 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: From Phil.Race at Sun.COM Mon Nov 26 04:10:53 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Sun, 25 Nov 2007 20:10:53 -0800 Subject: About bug submission In-Reply-To: <1196025189.3545.24.camel@nirvana.limasoftware.net> References: <1196025189.3545.24.camel@nirvana.limasoftware.net> Message-ID: <474A474D.2000404@sun.com> I can't answer all of this but if you add this link : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633656. to the bugzilla bug, then people will be able to click that see the state of the bug, since its now filed in the sun database, although its not immediate (24 hrs usually). Alternatively if any one wants to monitor bugs - as opposed to see current status - then they can sign up to http://mail.openjdk.java.net/mailman/listinfo/2d-bugupdates and they will get email updates to all bugs in this subcategory as they happen. -phil. Mario Torre wrote: > Hello all! > > I'm writing to try to start a discussion about a problem that I've found > while working on IcedTea today. > > We had a report from a user that filed a new bug on our bugzilla [1]. > > After a bit of investigation, it was obvious that the bug was an > upstream bug, and that was present in at least one version of the jdk > itself (I actually tested on 1.6.0.03). > > Now, I've resubmitted the same bug to the Sun database, but had to copy > all the data and the discussion back, as well as the proposed patch, > embedding references to our bugzilla directly in the comments. > > After that, the obvious move would be to close the bug from our side, > keeping a reference to upstream; but after all the efforts to search for > duplicated bugs, filing a new bug, copying all the data back, etc.. I > still don't have a reference id. > > Now, in this case all this was quite easy, as there were only a couple > of comments, but there may be cases where the procedure puts much more > efforts on the shoulder of us poor developers that already have days of > 36 hours long, and with developers I also mean GNU/Linux distro > packagers. > > I think it would be handy to have some sort of automatic procedure that > enable us to keep in sync in such cases, even if we still have to wait > up to 3 weeks to have a bug id assigned, but that at least let us not to > copy information around. > > Well, I don't really know what this common procedure could be, but at > least some easier way to forward bugs upstream. > > Both Fedora and Debian for example have bug databases in which they > collect user bugs, filter them to see if they are specific for the > distribution and if not, forward them. > > What do you think? > > Thanks, > Mario > > [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=81 > > P.S. please, explicitly CC me as for some reason I don't get mails back > from the various mailing lists, thank you. > From David.Herron at Sun.COM Mon Nov 26 05:05:32 2007 From: David.Herron at Sun.COM (David Herron) Date: Sun, 25 Nov 2007 21:05:32 -0800 Subject: About bug submission In-Reply-To: <1196025189.3545.24.camel@nirvana.limasoftware.net> References: <1196025189.3545.24.camel@nirvana.limasoftware.net> Message-ID: <474A541C.3030605@sun.com> Mario, FWIW I've forwarded the bug information to the quality team and I'm hoping to find out why we missed that one (since you found it using one of our demo cases) FYI the bugs submitted through bugs.sun.com are screened before being posted to the bug system. The screening process can take several days depending on the current influx of bugs. I suppose Phil is saying this one has already been processed and will be visible shortly. Of course there's no inter-bug-tracking-system-protocol which can automatically propogate bugs from one system to an upstream or downstream system. Of course that's a desired thing. Of course there are dozens of hurdles to jump to get such a thing implemented, and they aren't all technical hurdles either. For example for a non-Sun person to automatically enter a bug into Sun's bug system, well, there's several IT policies which would prevent us from doing so. IT policies which were decided prior to the age of widespread Open Source at Sun. As I understand it sometime relatively "soon" the openjdk.java.net site will have improvements made including a public bug tracking system. Life ought to be more flexible when that occurs. Mark Reinhold posted about this a couple weeks back. http://blogs.sun.com/mr/entry/under_construction What sort of automatic system would you be looking for? - David Herron Mario Torre wrote: > Hello all! > > I'm writing to try to start a discussion about a problem that I've found > while working on IcedTea today. > > We had a report from a user that filed a new bug on our bugzilla [1]. > > After a bit of investigation, it was obvious that the bug was an > upstream bug, and that was present in at least one version of the jdk > itself (I actually tested on 1.6.0.03). > > Now, I've resubmitted the same bug to the Sun database, but had to copy > all the data and the discussion back, as well as the proposed patch, > embedding references to our bugzilla directly in the comments. > > After that, the obvious move would be to close the bug from our side, > keeping a reference to upstream; but after all the efforts to search for > duplicated bugs, filing a new bug, copying all the data back, etc.. I > still don't have a reference id. > > Now, in this case all this was quite easy, as there were only a couple > of comments, but there may be cases where the procedure puts much more > efforts on the shoulder of us poor developers that already have days of > 36 hours long, and with developers I also mean GNU/Linux distro > packagers. > > I think it would be handy to have some sort of automatic procedure that > enable us to keep in sync in such cases, even if we still have to wait > up to 3 weeks to have a bug id assigned, but that at least let us not to > copy information around. > > Well, I don't really know what this common procedure could be, but at > least some easier way to forward bugs upstream. > > Both Fedora and Debian for example have bug databases in which they > collect user bugs, filter them to see if they are specific for the > distribution and if not, forward them. > > What do you think? > > Thanks, > Mario > > [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=81 > > P.S. please, explicitly CC me as for some reason I don't get mails back > from the various mailing lists, thank you. > From neugens at limasoftware.net Mon Nov 26 13:59:54 2007 From: neugens at limasoftware.net (Mario Torre) Date: Mon, 26 Nov 2007 14:59:54 +0100 Subject: About bug submission In-Reply-To: <474A541C.3030605@sun.com> References: <1196025189.3545.24.camel@nirvana.limasoftware.net> <474A541C.3030605@sun.com> Message-ID: <1196085594.5405.53.camel@nirvana.limasoftware.net> Il giorno dom, 25/11/2007 alle 21.05 -0800, David Herron ha scritto: [--- Long mail follow ---] Hello David, Phil, > Mario, FWIW I've forwarded the bug information to the quality team and > I'm hoping to find out why we missed that one (since you found it using > one of our demo cases) Thanks for the quick and kind replies. Actually I did not find the bug, only tracked down the problem, but I would like to point that this mail was not intended to try to resolve this bug or to push a quick reference in the Sun bug database (though of course I'm happy this was the result :), just to try to address a need that I have found and, talking to other hackers in #classpath, it's felt as a general problem. Also, I'm really happy (and though I missed the blog post from Mark Reinhold I had no doubt about that) to see that this will be addressed at some time in the not so distant future. > Of course there's no inter-bug-tracking-system-protocol which can > automatically propogate bugs from one system to an upstream or > downstream system. Of course that's a desired thing. Of course there > are dozens of hurdles to jump to get such a thing implemented, and they > aren't all technical hurdles either. For example for a non-Sun person > to automatically enter a bug into Sun's bug system, well, there's > several IT policies which would prevent us from doing so. IT policies > which were decided prior to the age of widespread Open Source at Sun. I would not change that necessarily, of course easing the procedure is always good, but I understands the needs behind this, and I'm not against waiting for few days (or up to few weeks, FWIW) to have a valid id number. I only think that we could setup a procedure that easy the way bugs are submitted. > What sort of automatic system would you be looking for? As this will require time, talking about this procedure now may sound a bit premature, but anyway, I want to share with you my experience. As you probably know, we use eclipse (if not emacs or vi) to develop classpath, and eclipse has a nice plugin named mylyn that connects to the various bug databases and let you perform queries, and follow progresses of bugs. Though I prefer the web interface in this case, it's handy as you can track changes directly in the IDE. Now, we could just have some system that simply fetch bug data from a source and copy all the relevant fields into the main bug database, like mylyn does. This could work in both directions (Sun<->IcedTea<->Distributors). This way, to submit a bug you always have to follow whatever procedure is needed (say, have a valid account, wait for a first review etc...), but filing the bug data itself is automatic, and ensures that once done and accepted, the bug is linked and we can track the lifetime of this bug in any bug system. Example test case: ---------- Guido Rossi, developer of John Doe Linux distribution finds a bug in IcedTea, and submit it to our bugzilla. Laura Palmer, fellow Classpath contributor, read the bug entry and find it's an upstream problem. She then goes to file it upstream. After log in and having filled the preliminary data (What module it belongs to, what version of the jdk was tested etc..), then she points the bug id of the IcedTea bugzilla, instead of copying all the data from this database. The system then copies all the relevant data (actually it could link it, so changes in one system are also added to the other). After a couple of days, Laura gets a mail from Bob at Sun, kindly telling the new bug id in the upstream bug system. Laura the can link back the bug from upstream, so that the bug can be tracked easily. End of example test case ---------- If we do that in public, we can also share some code needed to adapt a similar procedure to other bug systems/projects. I would also volunteer for that, if there is interest, and given someone helps me with the details. The end result would be to also increase chances to fix the bugs in question, because tracking downstream an upstream bug let a casual developer that finds the bug in his distribution bugzilla and has the skill to code the fix, to actually fix the bug and contribute the fix back. Of course, just an idea, feel free to mark is a "dumb" one :) Thanks, 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: From Tom.Marble at Sun.COM Mon Nov 26 16:28:08 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Mon, 26 Nov 2007 10:28:08 -0600 Subject: Jalimo @ FOSDEM 'Free Java Meeting' In-Reply-To: <47460D98.9020103@gmx.net> References: <47460D98.9020103@gmx.net> Message-ID: <474AF418.3040501@sun.com> Robert Schuster wrote: > I have seen the request to participate with a talk at the 'Free Java > Meeting' at FOSDEM'08[0]. I would like to do so and present JaLiMo which > is a project which aims to bring a Java(-like) environment to > Linux-based Mobile devices (hence the name :) ). Mobile in the sense of > mobile phones, PDAs and internet tablets/UMPC. > [...] every other distribution can benefit from our work, > too. Oh, yes: Everything is free and open-source software. :) This sounds like a great idea! We will have representation from our own phoneME team so having a part of the agenda on mobile open source Java makes sense. I see you are already on the wiki.... As we get closer (and, of course, assuming we get formal approval for our DevRoom today :) ) we will try to schedule talks into specific time slots. Thanks! --Tom From Kelly.Ohair at Sun.COM Fri Nov 30 19:11:46 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 30 Nov 2007 11:11:46 -0800 Subject: Build 24 promotion and the Mercurial Transition Status Message-ID: <47506072.5030509@sun.com> Build 24 and the Mercurial Transition Status: * We are finishing up our Mercurial dryrun this week. In the next few days, all the repositories at http://hg.openjdk.java.net/ will be re-initialized, making them unrelated to the previous experimental ones. They will contain the official starting sources, which will be the same sources we started the dryrun with, and the same as Build 23, so don't be expecting to see developer changes, yet. * Once we have the official jdk7 repositories, we will creating potential Build 24 bits (probably on Mon or Tues), and our release engineering team will have these bits go through some very basic testing before we officially promote them and declare Build 24 done. The release engineering team will be creating some mercurial tags and pushing them into the master jdk7 repositories to label Build 24 when the promotion happens, hopefully Tues or Wed next week. * Internally, we'll need a few days after that to get ourselves re-setup for developers to start doing pushes into their team repositories for Build 25. Since all these team areas are available at http://hg.openjdk.java.net/, everyone should start seeing the jdk7 development 'live', as it happens. * It's not clear when the first team integration into the master jdk7 area for Build 25 will happen. We are still trying to nail down some of our detailed procedures on how team integrations will work, and we'll probably adjust them over time. -kto