From sacadmin Mon Jun 26 16:09:48 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5QN9lcI014688 for ; Mon, 26 Jun 2006 16:09:47 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5QN9lMr027198 for ; Mon, 26 Jun 2006 16:09:47 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5QN9ltI023233 for ; Mon, 26 Jun 2006 16:09:47 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5QN9lIH023232 for psarc@sac.sfbay.sun.com; Mon, 26 Jun 2006 16:09:47 -0700 (PDT) Date: Mon, 26 Jun 2006 16:09:46 -0700 From: Danek Duvall To: psarc@sac.sfbay.sun.com Subject: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060626230946.GI1876@scuba.sfbay.sun.com> Mail-Followup-To: psarc@sac.sfbay.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 5540 I'm sponsoring this fast-track for myself. Due to the July 4 holiday, I'm extending the timer to two weeks, timing out on Monday, July 10. If it can be resolved sooner than that, though, I wouldn't mind. The man pages as shipped are available in the materials directory, for further perusal. Thanks, Danek 1. Summary This project proposes to add the source code management (SCM) system Mercurial[1] to the SFW consolidation for delivery on Solaris. This project requests a Minor release binding. 2. Background The OpenSolaris project[2] introduced new requirements on the development process for the components of Solaris which were planning on being open-sourced. One set of requirements revolved around the capabilities of the SCM that would be used[3]. After an extended evaluation, it was determined that Mercurial would be the most appropriate distributed SCM for OpenSolaris projects that needed such a tool. The version of Mercurial at the time of this writing is 0.9, though this project is not specific about the version it intends to integrate. Any architectural changes between 0.9 and future versions will be ARCed prior to integration. 3. Architecture Mercurial is a distributed SCM, meaning that development on a project managed by Mercurial can be done in parallel in different repositories scattered across different machines, each containing the full history of the project. As developers wish to create a release, one such repository may be designated as the "primary", and changes from other repositories merged into it without loss of history. All repositories for a project may be considered peers, though convention may assign a heirarchy to them. Code sharing can be performed via filesystem access, including NFS, http/https, and a byte-stream protocol (normally tunnelled by ssh), though the http support is currently restricted to read-only operations. Mercurial doesn't provide any native form of access control or authentication, instead relying on the underlying access mechanisms (filesystem ACLs, http authentication, etc.) or custom extensions to do so. Mercurial is written in Python, with a few core pieces (amounting to about 5% of the code) written in C for performance. It is released under version 2 of the GPL. Mercurial may be extended in two ways. Extensions may be written to augment core functionality -- adding new commands is the primary target -- and per-repository or per-user hooks can be written which Mercurial will run before or after certain transactions on the repository. This project depends on PSARC/2005/532[4] to provide Python 2.4 (and to move Python to its final location in /usr/bin), as well as PSARC/2005/555[5] to provide a standard location and mechanism on Solaris to find non-core Python extensions. 4. Interfaces Exported Interface Stability Notes ------------------ --------- ----- SUNWmercurial Committed Package name /usr/bin/hg Committed Executable location /usr/bin/hgmerge Committed Executable location hg commandline Committed options, subcommands and their options hg backout Volatile hg clone Volatile hg copy Volatile hg locate Volatile hg manifest Volatile hg merge Volatile hg parents Volatile hg pull Volatile hg rename Volatile hg revert Volatile hg status Volatile hg update Volatile "mercurial" Committed Python package name for core functionality "hgext" Committed Python package name for extensions /etc/mercurial/hgrc Committed Path to system config file /etc/mercurial/hgrc.d/*.rc Committed Pattern of other system config files $HOME/.hgrc Committed Path to user config file hgrc contents Committed Core commands config only /.hgignore Committed List of files to ignore HGEDITOR Committed Environment variable HGMERGE Committed Environment variable HGRCPATH Committed Environment variable HGUSER Committed Environment variable /usr/demo/mercurial Committed Place to put contributed files from the hg distro revlog/index Committed File formats Private wire protocol Committed Private All programmatic components of Mercurial which appear to be interfaces (i.e., class names, variables, methods, etc.) are Volatile. Future project maturity may result in the upgrading of the stability of these interfaces. Note that some of the hg subcommands are marked as Volatile which appear to be (and are) critical to daily operation. There is some work being done here to clean up the UI (such as using -r consistently as an argument taking a revision option, which is not what, say, "status" and "update" do), and the various "undo"-like operations are still undergoing some semantic and name changes. The authors expect that this will settle down by version 1.0, at which point we can revise the stability levels to Committed. Note that despite the declaration of /etc/mercurial as an interface, this project does not intend to deliver any files beneath it; hence no separate package to do so. Imported Interface Specified in? ------------------ ------------- ssh PSARC/2001/212 python 2.4 PSARC/2005/534 vendor-packages PSARC/2005/555 5. References 1. http://www.selenic.com/mercurial/ 2. http://www.opensolaris.org/os/ 3. http://www.opensolaris.org/os/community/tools/scm/ 4. PSARC/2005/532 Python migration from /usr/sfw to /usr and upgrade to v2.4.x 5. PSARC/2005/555 Python "vendor-packages" support From sacadmin Tue Jun 27 03:44:19 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5RAiIwA004314 for ; Tue, 27 Jun 2006 03:44:18 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5RAiHi7017164 for ; Tue, 27 Jun 2006 03:44:18 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5RAiCcg014853 for ; Tue, 27 Jun 2006 11:44:12 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1I00G01LQHQQ00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 11:44:12 +0100 (BST) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1I001ORLTNY250@d1-emea-10.sun.com> for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 11:44:12 +0100 (BST) Date: Tue, 27 Jun 2006 11:44:11 +0100 From: Darren J Moffat Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] In-reply-to: <20060626230946.GI1876@scuba.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: psarc@sac.sfbay.sun.com Message-id: <44A10BFB.1070208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20060626230946.GI1876@scuba.sfbay.sun.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 176 Exactly what do you import from ssh ? How is the http transport done, is there a daemon or is there some plugin for Apache that isn't part of this case ? -- Darren J Moffat From sacadmin Tue Jun 27 06:56:13 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5RDuDtC009119 for ; Tue, 27 Jun 2006 06:56:13 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5RDuCnI010826; Tue, 27 Jun 2006 06:56:12 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5RDuCNs026893; Tue, 27 Jun 2006 06:56:12 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5RDuBYn026892; Tue, 27 Jun 2006 06:56:11 -0700 (PDT) Date: Tue, 27 Jun 2006 06:56:11 -0700 From: Danek Duvall To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060627135611.GL21858@scuba.sfbay.sun.com> Mail-Followup-To: Darren J Moffat , psarc@sac.sfbay.sun.com References: <20060626230946.GI1876@scuba.sfbay.sun.com> <44A10BFB.1070208@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A10BFB.1070208@Sun.COM> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 1397 On Tue, Jun 27, 2006 at 11:44:11AM +0100, Darren J Moffat wrote: > Exactly what do you import from ssh ? Its commandline -- ssh is invoked as ssh [user@]host[ -p port] hg -R serve --stdio where "ssh" is configurable to something else. So, I guess, in particular the "host" and "user@host" syntax, the -p flag and argument, and the fac that it takes an unquoted string after all its options as a command to run on the other end. > How is the http transport done, is there a daemon or is there some plugin > for Apache that isn't part of this case ? Both. It has a built-in http server (well, Python does, mercurial just uses it), but it's strongly suggested to use one of the CGI scripts that come with it. It still uses Python's web server code, but lets Apache handle the connections, for better scaling (Python's web server isn't threaded, so you get better performance with Apache). I presume that any other web server could be used, as well. I don't install the CGI scripts by default (outside /usr/demo) since you need to modify them a touch to configure them, and I don't know if there's a way to install CGI script disabled. Until we have that kind of control over Apache, it seemed cleaner to let the user do it. Which brings up the question of how othe user knows about /usr/demo/mercurial, and that obviously needs to be added to the man page. Thanks, Danek From sacadmin Tue Jun 27 07:03:29 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5RE3Tg8009203 for ; Tue, 27 Jun 2006 07:03:29 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5RE3Sf8028196 for ; Tue, 27 Jun 2006 07:03:28 -0700 (PDT) Received: from d1-emea-05.sun.com (d1-emea-05.sun.com [192.18.2.115] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5RE3LO6021461 for ; Tue, 27 Jun 2006 15:03:21 +0100 (BST) Received: from conversion-daemon.d1-emea-05.sun.com by d1-emea-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1I00G01UAMYF00@d1-emea-05.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 15:03:21 +0100 (BST) Received: from [129.156.173.21] by d1-emea-05.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1I00MT4V1KP850@d1-emea-05.sun.com> for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 15:03:21 +0100 (BST) Date: Tue, 27 Jun 2006 15:03:20 +0100 From: Darren J Moffat Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] In-reply-to: <20060627135611.GL21858@scuba.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: psarc@sac.sfbay.sun.com Message-id: <44A13AA8.3040000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20060626230946.GI1876@scuba.sfbay.sun.com> <44A10BFB.1070208@Sun.COM> <20060627135611.GL21858@scuba.sfbay.sun.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 1012 Danek Duvall wrote: > On Tue, Jun 27, 2006 at 11:44:11AM +0100, Darren J Moffat wrote: > >> Exactly what do you import from ssh ? > > Its commandline -- ssh is invoked as > > ssh [user@]host[ -p port] hg -R serve --stdio Okay thats what I expected and I have no issue with that it is (in new taxonomy) Committed any way. >> How is the http transport done, is there a daemon or is there some plugin >> for Apache that isn't part of this case ? > > Both. It has a built-in http server (well, Python does, mercurial just > uses it), but it's strongly suggested to use one of the CGI scripts that > come with it. It still uses Python's web server code, but lets Apache > handle the connections, for better scaling (Python's web server isn't > threaded, so you get better performance with Apache). I presume that any > other web server could be used, as well. Any chance, not needed as part of this project, of an SMF service for this with instances per repository :-) -- Darren J Moffat From sacadmin Tue Jun 27 07:11:16 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5REBG9C009225 for ; Tue, 27 Jun 2006 07:11:16 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5REBFDd016613; Tue, 27 Jun 2006 07:11:15 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5REBFS5026998; Tue, 27 Jun 2006 07:11:15 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5REBEew026997; Tue, 27 Jun 2006 07:11:14 -0700 (PDT) Date: Tue, 27 Jun 2006 07:11:14 -0700 From: Danek Duvall To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060627141114.GM21858@scuba.sfbay.sun.com> Mail-Followup-To: Darren J Moffat , psarc@sac.sfbay.sun.com References: <20060626230946.GI1876@scuba.sfbay.sun.com> <44A10BFB.1070208@Sun.COM> <20060627135611.GL21858@scuba.sfbay.sun.com> <44A13AA8.3040000@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A13AA8.3040000@Sun.COM> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 774 On Tue, Jun 27, 2006 at 03:03:20PM +0100, Darren J Moffat wrote: > Any chance, not needed as part of this project, of an SMF service for > this with instances per repository :-) SMF support would be pretty cool, but I don't believe that SMF quite has the support for turning on and off parts of a running apache instance. I don't think it's appropriate to have each repo running a separate apache instance (which would be the quick 'n' easy way of doing what you describe), and I'm not even convinced that a separate apache instance (from its normal web and print services) for all repos is really appropriate either. Once Apache has full SMF integration, it's probably worth looking at this again. Until then, though, I don't think it really buys us much. :-/ Danek From sacadmin Tue Jun 27 07:28:19 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5RESISr009699 for ; Tue, 27 Jun 2006 07:28:18 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5RESIg3022816 for ; Tue, 27 Jun 2006 07:28:18 -0700 (PDT) Received: from d1-emea-06.sun.com ([192.18.2.116]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5RESAnJ018665 for ; Tue, 27 Jun 2006 15:28:12 +0100 (BST) Received: from conversion-daemon.d1-emea-06.sun.com by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1I00F01W5QEM00@d1-emea-06.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 15:28:10 +0100 (BST) Received: from [129.156.173.21] by d1-emea-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1I00G41W6XFC60@d1-emea-06.sun.com> for psarc@sac.sfbay.sun.com; Tue, 27 Jun 2006 15:28:10 +0100 (BST) Date: Tue, 27 Jun 2006 15:28:09 +0100 From: Darren J Moffat Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] In-reply-to: <20060627141114.GM21858@scuba.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Darren J Moffat , psarc@sac.sfbay.sun.com Message-id: <44A14079.40701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20060626230946.GI1876@scuba.sfbay.sun.com> <44A10BFB.1070208@Sun.COM> <20060627135611.GL21858@scuba.sfbay.sun.com> <44A13AA8.3040000@Sun.COM> <20060627141114.GM21858@scuba.sfbay.sun.com> User-Agent: Mail/News 1.5.0.2 (X11/20060515) Status: RO Content-Length: 647 Note this has gone off in a tangent and for me does not have any bearing on the outcome of this case which I am happy with as specified. Danek Duvall wrote: > On Tue, Jun 27, 2006 at 03:03:20PM +0100, Darren J Moffat wrote: > >> Any chance, not needed as part of this project, of an SMF service for >> this with instances per repository :-) > > SMF support would be pretty cool, but I don't believe that SMF quite has > the support for turning on and off parts of a running apache instance. I was actually thinking about the non Apache case. We we really know if performance isn't acceptable and Apache must be used ? -- Darren J Moffat From sacadmin Tue Jun 27 11:40:07 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5RIe7VC009643 for ; Tue, 27 Jun 2006 11:40:07 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5RIe6Xv014952; Tue, 27 Jun 2006 11:40:06 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5RIe6Zj000051; Tue, 27 Jun 2006 11:40:06 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5RIe5tk000050; Tue, 27 Jun 2006 11:40:05 -0700 (PDT) Date: Tue, 27 Jun 2006 11:40:05 -0700 From: Danek Duvall To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060627184005.GW1876@scuba.sfbay.sun.com> Mail-Followup-To: Darren J Moffat , psarc@sac.sfbay.sun.com References: <20060626230946.GI1876@scuba.sfbay.sun.com> <44A10BFB.1070208@Sun.COM> <20060627135611.GL21858@scuba.sfbay.sun.com> <44A13AA8.3040000@Sun.COM> <20060627141114.GM21858@scuba.sfbay.sun.com> <44A14079.40701@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A14079.40701@Sun.COM> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 984 On Tue, Jun 27, 2006 at 03:28:09PM +0100, Darren J Moffat wrote: > I was actually thinking about the non Apache case. We we really know if > performance isn't acceptable and Apache must be used ? Ah, that makes better sense. No, I haven't done the testing myself; it's merely "common knowledge" in the mercurial community that this needs to be done. I should also correct myself -- there was a patch that went into 0.9 that enables a threaded http server. I don't know if the tonic team did any load testing as part of the evaluation process -- I don't think so, but I could be wrong -- but we should do so before we do the ON roll-out. Note that (as of 0.9), http is used for anonymous pull only, and so is probably not as exciting as all that. Push over https (with mandatory authentication) has just made it into the development tree, and will likely be in the next released version, but it's probably a little too early to talk about what it'll look like by then. Danek From sacadmin Wed Jun 28 10:58:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SHwHkO004753 for ; Wed, 28 Jun 2006 10:58:17 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5SHwHMr001768 for ; Wed, 28 Jun 2006 10:58:17 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5SHwGE4009124 for ; Wed, 28 Jun 2006 10:58:16 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5SHwG2t009123 for psarc@sac.sfbay.sun.com; Wed, 28 Jun 2006 10:58:16 -0700 (PDT) Date: Wed, 28 Jun 2006 10:58:16 -0700 From: Danek Duvall To: psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060628175816.GL1876@scuba.sfbay.sun.com> Mail-Followup-To: psarc@sac.sfbay.sun.com References: <20060626230946.GI1876@scuba.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060626230946.GI1876@scuba.sfbay.sun.com> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 1178 I apologize for not showing up to PSARC this morning, but I'm informed that it was approved. The question was raised why I chose a Minor release binding. The reason is that I'm a touch uncomfortable with the stability classifications as they are. While I believe that the Mercurial developers are interested in interface stability for the same reasons that we are, this is still a pre-1.0 product, and I believe that there is still some (though small) likelihood of breakage before 1.0 ships. Running that through for a Minor release of Solaris is pretty straightforward, considering that Nevada is likely to ship well after Mercurial 1.0. But should Mercurial 0.9 get released as a patch, then it may not be able to to be patched to 1.0 in the lifetime of S10. There's also the issue that Mercurial relies on Python 2.4, and that got a Minor binding, and is highly unlikely ever to be patched back to S10. Perhaps these are issues that are better dealt with by the c-team, but I felt that it'd be better to make the statement of intent here. > python 2.4 PSARC/2005/534 Oh, and the case here is wrong -- it's PSARC/2005/532. Apologies for the typo. Thanks, Danek From sacadmin Wed Jun 28 12:52:45 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SJqi0K009517 for ; Wed, 28 Jun 2006 12:52:45 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5SJqhIo023571; Wed, 28 Jun 2006 15:52:43 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SJqhk5008606; Wed, 28 Jun 2006 15:52:43 -0400 (EDT) Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] From: Bill Sommerfeld To: Danek Duvall Cc: psarc@sac.sfbay.sun.com In-Reply-To: <20060628175816.GL1876@scuba.sfbay.sun.com> References: <20060626230946.GI1876@scuba.sfbay.sun.com> <20060628175816.GL1876@scuba.sfbay.sun.com> Content-Type: text/plain Message-Id: <1151524362.7274.60.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.338 Date: Wed, 28 Jun 2006 15:52:43 -0400 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1095 On Wed, 2006-06-28 at 13:58, Danek Duvall wrote: > While I believe that the Mercurial developers are interested in > interface stability for the same reasons that we are, this is still a > pre-1.0 product, and I believe that there is still some (though small) > likelihood of breakage before 1.0 ships. Running that through for a Minor > release of Solaris is pretty straightforward, considering that Nevada is > likely to ship well after Mercurial 1.0. But should Mercurial 0.9 get > released as a patch, then it may not be able to to be patched to 1.0 in the > lifetime of S10. Understood. My (unopposed) suggestion during arc business was that the submitter could make a self-reviewed change to Patch binding at their option. > There's also the issue that Mercurial relies on Python 2.4, and that got a > Minor binding, and is highly unlikely ever to be patched back to S10. Is this dependency anything more than an implementation detail? i.e., could we, in an update, ship python 2.4 in an alternate install location and point the update's version of mercurial at it? - Bill From sacadmin Wed Jun 28 13:06:27 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SK6QIg010256 for ; Wed, 28 Jun 2006 13:06:27 -0700 (PDT) Received: from scuba.sfbay.sun.com (scuba.SFBay.Sun.COM [129.146.175.60]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5SK6QIe017767 for ; Wed, 28 Jun 2006 13:06:26 -0700 (PDT) Received: from scuba.sfbay.sun.com (localhost [127.0.0.1]) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k5SK6QFU010831; Wed, 28 Jun 2006 13:06:26 -0700 (PDT) Received: (from dduvall@localhost) by scuba.sfbay.sun.com (8.13.5+Sun/8.13.5/Submit) id k5SK6QBe010830; Wed, 28 Jun 2006 13:06:26 -0700 (PDT) Date: Wed, 28 Jun 2006 13:06:25 -0700 From: Danek Duvall To: Bill Sommerfeld Cc: psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] Message-ID: <20060628200625.GP1876@scuba.sfbay.sun.com> Mail-Followup-To: Bill Sommerfeld , psarc@sac.sfbay.sun.com References: <20060626230946.GI1876@scuba.sfbay.sun.com> <20060628175816.GL1876@scuba.sfbay.sun.com> <1151524362.7274.60.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1151524362.7274.60.camel@thunk> User-Agent: mutt-ng/devel-r535 (SunOS) Status: RO Content-Length: 614 On Wed, Jun 28, 2006 at 03:52:43PM -0400, Bill Sommerfeld wrote: > Understood. My (unopposed) suggestion during arc business was that the > submitter could make a self-reviewed change to Patch binding at their > option. Cool, thanks. > > There's also the issue that Mercurial relies on Python 2.4, and that got a > > Minor binding, and is highly unlikely ever to be patched back to S10. > > Is this dependency anything more than an implementation detail? i.e., > could we, in an update, ship python 2.4 in an alternate install location > and point the update's version of mercurial at it? Of course. Danek From sacadmin Thu Jun 29 08:03:18 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TF3III008755 for ; Thu, 29 Jun 2006 08:03:18 -0700 (PDT) Received: from [129.150.12.95] (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TF3G83455584; Thu, 29 Jun 2006 08:03:17 -0700 (PDT) Message-ID: <44A3EBB2.1080403@sun.com> Date: Thu, 29 Jun 2006 05:03:14 -1000 From: Joseph Kowalski User-Agent: Mail/News 1.5.0.2 (X11/20060515) MIME-Version: 1.0 To: Bill Sommerfeld CC: Danek Duvall , psarc@sac.sfbay.sun.com Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] References: <20060626230946.GI1876@scuba.sfbay.sun.com> <20060628175816.GL1876@scuba.sfbay.sun.com> <1151524362.7274.60.camel@thunk> In-Reply-To: <1151524362.7274.60.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 490 Bill Sommerfeld wrote: > > Is this dependency anything more than an implementation detail? i.e., > could we, in an update, ship python 2.4 in an alternate install location > and point the update's version of mercurial at it? > > - Bill > Ah, the slippery slope to becoming the next libnss. Should another project assert a similar requirement for python 2.4, would we require them to share that copy? If we wouldn't why are we pushing for sharing instances of nss/nspr? - jek3 From sacadmin Thu Jun 29 08:24:02 2006 Received: from phys-d3-ha21sca-1 (phys-d3-ha21sca-1.SFBay.Sun.COM [129.145.155.163]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5TFO1s4009098 for ; Thu, 29 Jun 2006 08:24:02 -0700 (PDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1M00001O3A34@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for psarc@sac.sfbay.sun.com; Thu, 29 Jun 2006 08:24:01 -0700 (PDT) Received: from [192.168.0.101] (vpn-129-150-20-127.SFBay.Sun.COM [129.150.20.127]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1M00KCRO40O0@ha21sca-mail1.sfbay.sun.com>; Thu, 29 Jun 2006 08:24:01 -0700 (PDT) Date: Thu, 29 Jun 2006 08:23:54 -0700 From: Alan Coopersmith Subject: Re: PSARC 2006/417 Mercurial integration [Timeout: 07/10/2006] In-reply-to: <1151524362.7274.60.camel@thunk> To: Bill Sommerfeld Cc: Danek Duvall , psarc@sac.sfbay.sun.com Message-id: <44A3F08A.1070000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (X11/20060602) References: <20060626230946.GI1876@scuba.sfbay.sun.com> <20060628175816.GL1876@scuba.sfbay.sun.com> <1151524362.7274.60.camel@thunk> Status: RO Content-Length: 444 Bill Sommerfeld wrote: > Is this dependency anything more than an implementation detail? i.e., > could we, in an update, ship python 2.4 in an alternate install location > and point the update's version of mercurial at it? Python 2.4 is already in an alternate install location (2.3 shipped in /usr/sfw/bin, 2.4 in /usr/bin). -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering