VM "team"

[Ned Konz]

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:

/trunk
    platforms
    Cross (platform-independent)
    unix
    MacOs
    Win32

etc.

* 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.

/branches
    EXP-ned-cairo
      platforms
    EXP-craig-flow platforms

etc.

* 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):

/trunk
    platforms
        Cross
            plugins
                OSProcess
        unix
            plugins
                OSProcess

* 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:

/tags
    REL-Win32-3.6b-2
    REL-unix-3.7b-5
    DEV-unix-2005-05-07

etc.

* 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.

-- 
Ned Konz
http://bike-nomad.com/squeak/