Re: VM "team"

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

> On Thursday 10 March 2005 11:34 pm, [hidden email] 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.
>

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

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