[Cp-tools-discuss] GNU bytecode (was Re: gjdoc in Debian now, what about javap and javah ?)

[Alex Lancaster]

>>>>> "BJ" == Brian Jones <address@hidden> writes:

BJ> Alex Lancaster <address@hidden> writes:

>> Just wondering, does this mean that cp-tools is now the canonical
>> CVS location for gnu.bytecode?

BJ> No.

>> If not, why don't you merge your patch with the kawa project?

BJ> I will send the patch to the Kawa list again and see what happens.
BJ> Hopefully Per will accept it.

So all has been quiet on the Kawa front, was this reason for checking
in the local copy?

>> It's seems like a potential merge nightmare if we have two
>> repositories offering the same source.

BJ> One of the features of CVS is the ability to track 3rd party
BJ> software via import (and deal with your local changes).  I'm
BJ> sleeping well.

I realise that CVS can be used effectively to track 3rd party sources
and such, but my concern was more an organisational one.  People may
stumble upon the CVS repository in a google search via CVSweb or check
it out, thinking they have the canonical location of the bytecode
source, and think that it is part of cp-tools, not Kawa, not realising
that it's simply a local version for our internal purposes.

I know I've wasted time on what I thought was the final "real"
upstream source (CVS or otherwise) of a particular package, only to
find that it was a local copy, but that it was not labelled as such.
So I think minimally we should clearly mark it as so, in a README or
some such (i.e. tell people to not waste time generating patches
against our version).  It's no big deal, but it might prevent
confusion down the track (especially for any future cp-tools
maintainers).

Alex
-- 
  Alex Lancaster | Free Software Developer:  savannah.gnu.org, sourceforge.net