ned at squeakland.org
Tue Mar 15 18:11:40 UTC 2005
On Thursday 10 March 2005 11:34 pm, goran.krampe at bluefish.se wrote:
> Ian wrote:
>> I was also very clear, when we first adopted SF, that CVS was a
>> periodic backup of my source tree (and not the primary copy) and that the
>> only de-facto set of sources were in tarballs on my download page.
> Well, ok, but even if you made that clear it was never clear to a lot of us
> I think. Or at least a lot of us falsely presumed that the CVS repo was
> intended to be the master place. So again, I repeat - these kinds of things
> should IMHO be documented shortly and distinctly in a single place. I would
> like someone to do that, is that something you all agree with? Then I assume
> that this is not going to be the case from now on. The fact that stuff is
> being touched on Svn doesn't really tell me a thing in this regard, stuff
> was touched on SF too, but it was still not considered the "master site" of
> the unix source. There are advantages and disadvantages to making the
> repository be the primary copy of my sources. I haven't decided yet. Ok, now
> - I of course respect each and every port maintainer to make their own
> decisions regarding their ports (it is after all your code :)) - but let me
> just point out that what you now write is not known. I was under the
> distinct impression Andreas just told me that Svn is the master.
Would it be too much to ask that all the "official" VM maintainers commit to
some common practice and start trying to work together?
Why bother setting up a private repository if we're not going to use it?
I respect that different primary maintainers may have different preferred ways
to work, and different schedules. However, given that SVN is quite powerful
and flexible, can't we just agree to certain basic strategies?
This is a community, and if we really want to have others help with fixes and
enhancements, wouldn't it be better to make ongoing development actually
public and in one place?
My proposal is this (yes, I know it will mean that we will have to change the
way we work):
* Ongoing development on shared code (VMMaker, platforms/Cross) and on
"official" platform code is kept updated on SVN. Even if there is only a
single developer working on the main development branch of a particular
platform, they should keep the repository updated as often as they feel that
they have a version that can be built and tested by others.
* There is a single branch for the 'main' development branch of each platform.
The "Cross" branch also has a primary platform developer (Tim?). The primary
platform developer has admin control over this branch. So we'd have:
* All VM maintainers who have declared an interest in doing development, have
been accepted by the primary maintainers, and agree to follow the rules have
the ability to create their own branches for experimental work (their own
extensions, etc.). These are not meant as forks of the main platform
branches; if you're working on platform code you should be communicating with
the rest of the platform team.
* Acceptance of code into the official platform branches is decided by the
primary platform maintainer.
* VMMaker sources and/or distributions are also maintained under SVN control,
and is in sync with each of the branches that it appears on. This way someone
can get a particular branch in its entirety, and have the entire package
needed to build and test coherent sources.
* Additional platform- or plugin-specific Squeak code, documentation, test
code, scripts, demos, etc. should also be maintained on SVN, together with
the plugin or platform code that it works with. For instance, it's typical
that an optional plugin may have Squeak code to actually make it work. So for
instance (say for the OSProcess plugin):
* Tags should be used to mark buildable, testable versions of code/VMMaker
combinations for each branch. This goes for both released versions and
interim development versions that are known to be buildable and work well
enough to be testable. This way we can talk about a particular version using
something other than the version number. So:
* There is no hard-and-fast requirement that the trunk be buildable, but it
makes sense to make a reasonable effort to have the trunk mirror something
that is known to build.
* Official releases are first published as tags on SVN. If further packaging
is needed (like making .deb packages, packages including tools, etc.) then
that is done later. This
* When sub-teams (or even individual developers) are doing experimental work,
they should let the vm-dev list know, just in case someone else is also
working on the same thing (or has in the past). They should be encouraged to
update the SVN repository from time to time.
More information about the Vm-dev