Re: VM "team"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

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

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

Reply | Threaded
Open this post in threaded view
|

re: VM "team"

ccrraaiigg

 > [Ned's VM sources organization and access proposal]

        That would be wonderful.


-C

--
Craig Latta
improvisational musical informaticist
craig@{netjam.org, weather-dimensions.com, appliedminds.com}
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]



Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

Andreas.Raab
In reply to this post by ned-4
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, [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.
>

Reply | Threaded
Open this post in threaded view
|

re: VM "team"

Tim Rowledge-2
In reply to this post by ccrraaiigg
In message <[hidden email]>
          Craig Latta <[hidden email]> 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, [hidden email], http://sumeru.stanford.edu/tim
Terminal glare:  A look that kills...

Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

goran.krampe
In reply to this post by ned-4
Hi Ian!

(moved to vm-dev)

Ian Piumarta <[hidden email]> wrote:
> On Mar 15, 2005, at 13:23, [hidden email] wrote:
>
> > And it is a bit frustrating, AFAIK it still isn't in there
> > (getImageName). So the unix HEAD isn't compiling with the current
> > VMMaker
>
> It's compiling fine with the VMMaker shipped with 3.7-5898-full.

Ehum, cough. Ok, now the fog clears. :) I didn't notice VMMaker is
already included in 3.7, so I opened up SMLoader in a 5989-full,
selected VMMaker and installed it. Oops, bad move.

That will install the latest, which evidently is a beta for 3.8, but in
this case unfortunately marked as being for 3.7 (so SM will not
complain), though even if it tripped me up, that may be considered fine
- since it does after all *work* in 3.7.

I apologize for my utter VM-n00b-stupidity and still humbly conclude
that a little page somewhere explaining how to do this properly would at
least have helped me - and obviously all the other people stumbling on
this getImageName stuff - evidently they must all have been falling in
the same trap. :)

I know Ian has pretty detailed and good descriptions, but I think what
is lacking here is a more condensed howto that indeed includes this
stuff about VMMaker (haven't tested this, but I guess you see what I
mean):

- Get the full image for the official *current release*.
- Use the VMMaker installed in that image, or install the latest version
*for that release* (not newer). The trunk of the support code is meant
to build with the *released* VMMaker, not with the latest available.
- Check out trunk like this: yaddayadda
- Create configure script by doing:
        cd <somewhere>/squeak/platforms/unix/config
        ./configure && make
- Start VMMaker and set platforms path to
"<somewhere>/squeak/trunk/platforms" and src path to
"<somewhere>/squeak/trunk/src" (which you need to create)
- Then create directory <somewhere>/squeak/trunk/build

After that this should repeatedly build you a VM:
- Use VMMaker:
        Clean out source (the button)
        Make all plugins internal (or start with none)
        Generate all
- cd to <somewhere>/squeak/trunk/build and build it:
        rm -rf * && ../platforms/unix/config/configure && make

And to install, you can do make install etc. See Makefile for other
targets like for example only compiling plugins etc.

regards, Göran

PS. Ian, did you try with automake 1.8 or 1.9?

PSS. Still think a little page explaining the most important details
about the VM work process would be helpful. I don't think many people
are aware that Ian wants patches in the form of full files sent by email
for example.

Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

Andreas.Raab
> I apologize for my utter VM-n00b-stupidity and still humbly conclude
> that a little page somewhere explaining how to do this properly would at
> least have helped me - and obviously all the other people stumbling on
> this getImageName stuff - evidently they must all have been falling in
> the same trap. :)

More likely, they have been using a basic image (3.7 or 3.8). Which
reminds me: With the current SM, is there actually a way of marking
releases in a way that users will automatically get "their" version?

> I know Ian has pretty detailed and good descriptions, but I think what
> is lacking here is a more condensed howto that indeed includes this
> stuff about VMMaker (haven't tested this, but I guess you see what I
> mean):

http://squeak.hpl.hp.com/unix/devel.html
http://squeak.hpl.hp.com/unix/platforms/unix/doc/HowToBuildFromSource.html/index.html

Both seem quite applicable in this regard.

> PSS. Still think a little page explaining the most important details
> about the VM work process would be helpful. I don't think many people
> are aware that Ian wants patches in the form of full files sent by email
> for example.

Well, if they care to read they might now ;-)

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

goran.krampe
Hi!

Andreas Raab <[hidden email]> wrote:
> > I apologize for my utter VM-n00b-stupidity and still humbly conclude
> > that a little page somewhere explaining how to do this properly would at
> > least have helped me - and obviously all the other people stumbling on
> > this getImageName stuff - evidently they must all have been falling in
> > the same trap. :)
>
> More likely, they have been using a basic image (3.7 or 3.8). Which

Yeah, I did that too at first. ;)

> reminds me: With the current SM, is there actually a way of marking
> releases in a way that users will automatically get "their" version?

Yes, I assume you mean "their" as in "for their Squeak version". When
you do "install" on a package (not a specific release) it will try to
find the latest published release for your Squeak version (looking at
the categories).

And it will typically ask a bunch of questions if there are no published
ones, or if there is no version for your Squeak version etc, etc. So no,
not as good as full dependencies - but it helps.

> > I know Ian has pretty detailed and good descriptions, but I think what
> > is lacking here is a more condensed howto that indeed includes this
> > stuff about VMMaker (haven't tested this, but I guess you see what I
> > mean):
>
> http://squeak.hpl.hp.com/unix/devel.html
> http://squeak.hpl.hp.com/unix/platforms/unix/doc/HowToBuildFromSource.html/index.html
>
> Both seem quite applicable in this regard.

These were the docs I was indeed referring to. But when I looked at them
I didn't find much info about VMMaker. And yes, I did try the preloaded
VMMaker image, but that is a 3.6 image, so that isn't really the "HEAD"
of VM development. And also it failed with:

vm/vm.a(sqVirtualMachine.o)(.text+0x483): In function
`sqGetInterpreterProxy':
/home/gokr/svn/squeak/trunk/platforms/Cross/vm/sqVirtualMachine.c:315:
undefined reference to `isArray'
vm/vm.a(sqVirtualMachine.o)(.text+0x48e):/home/gokr/svn/squeak/trunk/pla
tforms/Cross/vm/sqVirtualMachine.c:316: undefined reference to
`forceInterruptCheck'
collect2: ld returned 1 exit status
make: *** [squeak] Error 1

...but I guess it would work if I checked out 3.6 from Svn using some
tag or so.
 
> > PSS. Still think a little page explaining the most important details
> > about the VM work process would be helpful. I don't think many people
> > are aware that Ian wants patches in the form of full files sent by email
> > for example.
>
> Well, if they care to read they might now ;-)
>
> Cheers,
>    - Andreas

cheers, Göran

PS. Also note that the current trunk for unix is based on a 3.7-beta
image (5868), which can be seen flashing by during the configure phase.
Ian and I discovered this a day or two ago and Ian used language "not
appropriate" for this forum :) :), it is a mistake, but I am not sure if
it has any known bad consequences.

Reply | Threaded
Open this post in threaded view
|

Re: VM "team"

David T. Lewis
In reply to this post by Andreas.Raab
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