On Thursday 10 March 2005 11:34 pm, goran.krampe@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's VM sources organization and access proposal]
That would be wonderful.
-C
In message 423748B0.5050003@netjam.org Craig Latta craig@netjam.org wrote:
[Ned's VM sources organization and access proposal]
That would be wonderful.
I pretty much agree. I can't be completely sure about the branching idea becasue I can't honestly claim to understand branching SVN. Keeping the latest VMMaker attached to the matching platforms code is definitely something I'd like to see. A 'safe' zip/tarball/whatever of the release platforms tree + VMMaker + copies of any/all doc would be very nice to see clearly available.
Compilable HEAD:-
We did pretty much agreee that the default checkout should be as sane as we could manage; I think we all understand that mistakes can happen. The nice thing about a repository like CVS or SVN is that anyone competent can revert problematic changes. For example, it looks like I probably inadvertently commited the recent changes to sq.h as part of updating some RISC OS code - blame unfamilarity with SVN. Anyone with access could have reverted it and mailed me to discuss what to do to fix it more elegantly.
VM Team 'leader':-
If anyone wants to list me as such I don't mind. If someone would like to pay me to do it fulltime I wouldn't either. If somebody else is daft enough to want the title, feel free.
Swiki doc:-
I made a pass through everything I could find that mentioned vm, vmmaker, etc a few weeks ago to at least expunge CVS/SF mentions and replace with SVN/SqF. There is quite a lot that could do with hacking out simply to clean out obsolete junk. It would be nce to end up with a simple set of pages that
describe how to get sources subpages with any special notes for each platform - how to fiddle with codeworrier or whatever describe how to run VMMaker describe how to build almost all redirected to platform specific pages describe some tests to see if it seems like a good build describe how to report problems and who to
I'd suggest that statically pickled copies should be in any 'safe tarball'.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Terminal glare: A look that kills...
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@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.
On Tue, Mar 15, 2005 at 01:02:58PM -0800, Andreas Raab wrote:
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:
<snip>
- 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
Just for the record, the OSProcess plugin is written in Squeak (Slang) and requires no C code to make it work. The only thing that appears in the platforms tree is a Makefile.inc that fixes up the include path for the C preprocessor. For what it's worth, I favor Andreas' view of keeping VMMaker code in the Squeak release, and the support code in SVN.
Dave
vm-dev@lists.squeakfoundation.org