Should we rename the MASTER forest?

[Peter B. Kessler]

Mark Reinhold wrote:

>> Date: Thu, 08 Nov 2007 19:53:21 +0000
>> From: Andrew John Hughes <gnu_andrew at member.fsf.org>
> 
>> jdk7 seems a bit odd, given that presumably the mercurial repositories will
>> live on beyond the release of version 7.  How about simply jdk?  Or am I
>> missing some subtle point that means we can't simply mark a snapshot that
>> was the jdk7 release?
> 
> Good question!
> 
> Yes, we could tag the final changeset in each tree, but ...
> 
> Our usual practice has been to freeze the master TeamWare workspaces for
> each release when that release goes final.  Successor releases, whether
> they're small update releases or the next big feature release, are
> developed in their own workspaces, which start out as clones of the
> original master.  This is, yes, different from the way that people tend
> to use centralized SCMs such as CVS and Subversion.
> 
> Transposing this to Mercurial: When JDK 7 ships then the jdk7 master
> forest will be archived, and work on JDK 8 will begin in a jdk8 forest,
> which will initially be a clone of jdk7.
> 
> One could argue that this practice arose in response to the inherent
> weaknesses of TeamWare, and that's largely true.  There are, however,
> at least two reasons to retain it:
> 
>   - Familiarity - This counts for a lot.  We're already forcibly
>     stretching the brains of Sun engineers to transition from TeamWare
>     to Mercurial; let's not stretch them more than absolutely needed.
> 
>   - Paranoia - So far Mercurial has been very robust in our experience,
>     but there is nonetheless a certain comfort in knowing that a
>     read-only, archived copy of every release forest is readily available
>     just in case something goes very wrong.  (Yes, of course we do
>     backups too, but restoring really old backups tends to be painful.)
> 
> None of this is cast in stone.  If down the road we find better reasons
> to have just one big JDK master forest then we can pretty easily make
> that happen.
> 
> To be clear, the URL for the JDK 7 master forests is currently
> 
>     http://hg.openjdk.java.net/jdk7/MASTER
> 
> but with my proposal will change to
> 
>     http://hg.openjdk.java.net/jdk7/jdk7
> 
> and live alongside the other JDK 7 integration forests:
> 
>     http://hg.openjdk.java.net/jdk7/2d
>     http://hg.openjdk.java.net/jdk7/awt
>     http://hg.openjdk.java.net/jdk7/build
>     http://hg.openjdk.java.net/jdk7/corba
>     http://hg.openjdk.java.net/jdk7/hotspot
>     http://hg.openjdk.java.net/jdk7/...
> 
> - Mark


The VM team (the hotspot/ subdirectory) has tended to work the other
way:  we have a repository we are all working on and when we get near
a release we make a clone of that and call it HotSpot-N.  But the
main repository keeps moving towards HotSpot-N+1.

That means that bug fixes that are needed in HotSpot-N have to be
forward-ported to the main repository.  Or, more likely, fixed in
the main repository and patched back to HotSpot-N.  I think the need
to fix things in two places will always be with us, no matter which
way we clone the repositories.

But as Neal points out, witht the main repository continuing forward,
the engineers don't sit on their hands (or on private, untested
workspaces) because management wants a release.  (I think the allocation
of testing resources is an orthogonal issue, but I understand QA's
reluctance to test individual engineer workspaces.)

If the top-level repository is called jdk, then it's weird that
there's a jdk/jdk subdirectory.  Can we think of a better name for
that?  jdk/jdk certainly isn't the whole JDK, since it doesn't
contain the VM, langtools, or the other important bits.  I'd let
the people that own that code come up with a name for it.

I understand the impetus to call the top-level repository openjdk.
At first I thought that would be confusing for the Sun engineers that
still have to deal with the parts of the JDK that aren't open yet.
But on second thought it might prevent accidents to have the stuff
that's open in a directory with "open" in its name.  In the short
term that might also remind people that OpenJDK is just the open
parts of the JDK, because of the parts that are still encumbered
(few and getting fewer).

My $0.02.

			... peter