From amitksaha at netbeans.org Fri Nov 2 07: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071102/5b5235d5/attachment.html From neojia at gmail.com Sat Nov 3 00: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 Sun Nov 4 19: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 05: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 07: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 08: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 08: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 10: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 11: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071105/410f7204/attachment.html -------------- 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 : http://mail.openjdk.java.net/pipermail/discuss/attachments/20071105/410f7204/attachment.bin From Peter.Kessler at Sun.COM Mon Nov 5 11: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 12: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 : http://mail.openjdk.java.net/pipermail/discuss/attachments/20071105/610a5660/attachment.bin From volker.simonis at gmail.com Mon Nov 5 12: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 12: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 13: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 : http://mail.openjdk.java.net/pipermail/discuss/attachments/20071105/68750174/attachment.bin From springer at reservoir.com Mon Nov 5 15: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 Mon Nov 5 22: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 Mon Nov 5 22: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 Mon Nov 5 22: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 Mon Nov 5 23: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 Mon Nov 5 23: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 Mon Nov 5 23: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 00: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 05: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 09: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 09: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 09: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 09: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071106/d4be854b/attachment.html From Dmitri.Trembovetski at Sun.COM Tue Nov 6 09: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 10: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 10: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 12: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 Tue Nov 6 18: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 Tue Nov 6 19: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 Tue Nov 6 19: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 Tue Nov 6 21: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 Tue Nov 6 21: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 03: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 09: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 09: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 09: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 10: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 10: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 10: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 10: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 10: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 11: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 11: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 11: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/a3a5b85d/attachment.html From Bradford.Wetmore at Sun.COM Thu Nov 8 11: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 12: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 12: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 12: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 12: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/55996bc8/attachment.html From gnu_andrew at member.fsf.org Thu Nov 8 12: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/2b30d764/attachment.html From roman at kennke.org Thu Nov 8 12: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 12: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 13: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 13: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/16e39ec3/attachment.html From Eric.Armstrong at Sun.COM Thu Nov 8 13: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 13: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 13: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 14: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: http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/5ba68d85/attachment.html From mr at sun.com Thu Nov 8 14: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