[Slightly OT] Source code management

Tim Rowledge tim at sumeru.stanford.edu
Wed Feb 6 19:31:31 UTC 2002


"Andreas Raab" <Andreas.Raab at gmx.de> is claimed by the authorities to have written:

> The problem's we're seeing are not related to VMMaker but to the (yet
> undiscussed) question about _what_ design works well depending on the
> various platforms and the working styles of people involved (and I'm not
> altogether happy with the current structure of the platforms tree but
> you know that too) as well as the question of where the "reference
> location" for support code is and who might get write access to what
> part.
An explanation of your problems with the tree structure would be very
helpful at this point. The only example problem that's been explicitly
discussed so far was the smooshing of all the internal plugins' code
into the same place as the core vm code, but that was fixed by Lex's
suggestion of a subtree for the internal plugins. I recall that you
suggested that the jpeglib (and mpeglib?) libraries ought to be
separated out, which has merits of cleanliness but possibly complicates
makefiles. What other problems do we need to solve? Note that the
current Windows makefile stuff on SF does not yet handle the intplugins
nor the no-file-copy regime. Coming soon, I'm sure.

> And you also know that my primary reason for not liking the idea
> of a central repository for everything is just that you never know who
> might (accidentally or not) mess up completely unrelated code. That's
> all I was referring to.
That would seem to be something that cvs/rcs/(most serious source
repositories) ought to be able to handle adequately, surely. Though,
yes, that is something of a tautology since any system that didn't do
it wouldn't count as a serious system.
Keep the list of people permitted to write files short (in fact I've
publically suggested that it ought to _not_ include anyone that actively
develops vm code so it has to go through a review before acceptance -
perhaps only Goran should be so deified?) and do regular, preferably
automated, build attempts to find (some kinds of) problems sooner rather
than later.

> 
> Sorry about that - I certainly didn't mean to accuse you of anything.
Glad to hear it.
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: VAX: Change vendor immediately (See BNE)




More information about the Squeak-dev mailing list