Re: JDK 1.1.5: Ready, set, go!

[Brian Behlendorf <brian@xxxxxxxxxxxxx>]

At 04:24 PM 12/15/97 -0500, Alex Boisvert wrote:
>On Fri, 12 Dec 1997, Brian Behlendorf wrote:
>
>> I'm not sure if this would overlap with Archie's offer, but I'm willing to
>> host a CVS repository for the patches so that they may be jointly
>> maintained by a group of folks.  This would be on the same box and using
>> the same resources as the Apache developers, and I'd be fine with giving
>> out a half dozen logins for those maintainers.
>
>Do you have experience sharing patches with CVS?  Right now, I have a "big
>patch file" which is a recursive rundown of all directories included in
>the distribution.  If we setup a CVS repository, we'll need to maintain a
>separate file for each modified file in the hierarchy.  Is this
>appropriate?

Since what you release is a set of patches, what we would do is import the
1.1.5 JDK source into the CVS hierarchy, and when we get ready to do a
release, do a "cvs diff -R" from the root directory specifying the
differences between the current base and the imported code.  Shouldn't be a
problem.  That way when one of the developers has the CVS tree checked out
they should be able to test the committed changes by recompiling.  The
downside is that we couldn't share access to the CVS tree (including cvsup
read-only access) with anyone who doesn't abide by the Sun license
agreements.  Also, when a new JDK comes out (e.g. 1.1.6) we can take the
patches applied against 1.1.5 and progressively apply them to 1.1.6 as a
new cvs module, until something doesn't patch cleanly, thus being a sign
that we need to modify something.

>How does the Apache developers work?  Do they have scripts to
>upload/download/maintain the patches?  

Approximately 19 people have cvs commit access to the tree.  When a patch
is committed a mail gets sent to a mailing list all these folks (and
others) are on, with a diff showing what was changed and the explanatory
comment.  Patches can be rolled back, but we have rarely needed to do that;
usually a patch is proposed on the development list, and if three people
give it a thumbs-up and no one vetos it the proposer has the "right" to
commit it.

Most CVS work takes place using remote CVS through ssh - see
http://dev.apache.org/ for more details.  Commit access requires a login on
the machine, but it can all be done remotely through ssh.

>Since you seem familiar with this, 
>can you setup an environment for the ports?  I'll send you my preferred
>login attributes now and others can do the same...

I'd like to get some feedback from others who think this is the right
approach to take; if you're the only one interested in working on it
directly then the effort of putting this under group change control isn't
worth it.  Anyone else?

In particular I'm somewhat concerned about the Sun license agreements cause
this to be a tricky proposition, and I'm also concerned it may 'taint' the
folks here and others involved from ever being able to work on Kaffe or
other clean room Java efforts.  Thoughts?

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects	brian@xxxxxxxxxx	 brian@xxxxxxxxxxxxx