VM "team"

[Andreas Raab]

Hi Ned,

This sounds good to me and I don't see many changes compared to current 
practice. The major change would be the one that I actually object to: 
Namely having the VMMaker code in SVN instead of having it with the 
appropriate Squeak release. This I really don't like. In my 
understanding, people who want to work with the VM should use:
* The Squeak version they want to build a VM from.
* A support code package matching that Squeak version.
The support code (e.g., the stuff written in C) should come from SVN, 
but the Squeak code (the portion which is translated) should come with 
Squeak, not with the C code.

Cheers,
   - Andreas

Ned Konz wrote:
> 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.
>