On 3/10/2011 3:13 AM, Alan Bateman wrote:
Fredrik Öhrström wrote:
I think it is important that a recent stock mercurial install
can check out the full openjdk with a single clone
command.
I.e. you should not have to install special extensions just
to get the source code.
I think this is a reasonable goal as it's probably confusing to folks
today that they need to do seven "hg clone" commands to get everything
(or else they need to go through hoops to get the forest extension
working if they want the convenience of the fclone command). At the same
time, and as Phil mentioned on another thread, I think most people are
working in only one or a small subset of the repositories. If you've got
the disk space then having all the repositories might not be a problem;
the important thing (from a productivity perspective) is to continue to
allow partial builds (meaning building a subset of the repositories and
augmenting that with pre-built bits of the other repositories) and of
course incremental builds within that when working in a specific area.
-Alan
I see no compelling reason to architect things to a single-command full
JDK source code pull using a stock Mercurial. That's a particular
solution to one problem, and by no means the only solution.
If we would like to make pulling a full JDK source tree simpler, then by
all means, let's include that as a possible goal. But let's not put the
cart before the horse, without fully understanding what we're looking
for in the big picture.
Before we get into implementation details, we need to discuss what we're
trying to accomplish.
As I see it, the source repository (in the generic sense, regardless of
how it is actually technically implemented) has several demands made
upon it:
(1) It should be designed to allow for maximum productivity of the
developers (where ever they are); meaning, it should *not* define the
way development works, but that developers should define how they work
will work as a whole, and then the repo structure should reflect this.
(1a) cloning/pulling the JDK should be as simple and as fast as
possible. We need to define which has higher priority: the ability,
speed, and simplicity of pulling/cloning a component part of the JDK, or
the ability/speed/simplicity of pulling/cloning the *entire* JDK
(1b) supporting partial and incremental builds is highly desirable
(2) It should provide for reasonable flexibility in forking and movement
of large chunks of code between portions of the JDK
(2a) In particular, it should allow for the possibility of
replacing chunks of the JDK wholesale with outside sources. The titular
example is the VM, which should be able to be replaced without screwing
up the rest of the JDK repository(s). However, the VM is not the only
place this is beneficial - we need to make sure that any defined
component can have a forklift replacement, without damaging the rest of
the JDK repository.
(3) Maintainers, Performance Analysis, and QA/QE folks need the ability
to quickly and easily identify discrete points in the source code
evolution - that is, the JDK must have some way to provide snapshot
capability (where, by "snapshot", I mean that it is possible to maintain
a system where a perpetual reference to a particular state of the JDK
repository can be made).
What other *DESIGN* goals do people see should have for the JDK repository?
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
