squeak-vmdev — CVS-related Virtual Machine Development Issues

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Tim R. <ti...@su...>]

In message <102...@ma...>
          G=F6ran Hultgren <gor...@bl...> wrote:


> PS. I am actually adding support for "P" in sqcvs - the CVS protocol
> is capability based and if the client says "Nope, I can't handle patch
> files" then those don't get sent by the server- no "P"s shows up. But t=
hat is a
> good thing to be able to handle so I just added it actually... :-) The =
unified
> diff is very easy to apply.
Things I'd like to see sqCVS handle:-

+ renaming - surely it isn't too hard to do the remove, commit, replace,
commit, handle paths & directories in one clean package? It's so painful
with plain cvs.

+ err, actually, that would cover it, since obviously removing & adding
would have been fixed as a side effect.

tim
--=20
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Tim R. <ti...@su...>]

In message <Pin...@ba...>
          Bert Freudenberg <be...@is...> wrote:


> Then you just don't use the right doc. It's mentioned in the info files as 
> well as here, for example:
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
Hmm, interesting - I had downloaded the single file version from there
some time ago and my copy is identical (in that area, anyway) _except_
for missing the section on 'P'. Guess it got updated.
I've grabbed the latest now anyway.

tim
-- 
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Stumped by anything child-proof.

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

Hi guys!

Quoting Bert Freudenberg <be...@is...>:
> On Mon, 13 May 2002, Tim Rowledge wrote:
> > > The update will tell you what files are modified "M"
and that will
> be
> > > committed.
> > > You can also then see if other people have just committed stuff
> ("P"/"U"
> > > etc) that you should take into account before committing.
> > Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
> > (when I managed to commit everybody's open files - I cn't imagine
> what
> > the logical argument in favour of that working was) and couldn't find
> an
> > explanation in any of my cvs doc (I have assorted webpages snarfed
> > locally that I use).
> 
> Then you just don't use the right doc. It's mentioned in the info files
> as 
> well as here, for example:
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
> 
> U The file was brought up to date with respect to the repository. 
> P Like `U', but the CVS server sends a patch instead of an entire file
> M The file is modified in your working directory.X
> C A conflict was detected while trying to merge your changes
> 
> -- Bert

Yes, a "U" is FULLY equivalent to a "P" - it means that your workingcopy was
just updated because someone has committed a new version of the file since you
last updated it. "M" means that the file in question has a local modification in
your working copy and if you commit it a new revision will be created for it.

Interestingly a file marked "M" could very well have been updated during the
update and automerged without conflict. You would have to study the output to
discover that actually - I don't think you can see that otherwise. A bit dumb.

Anyway - if you have made a change, compiled, tested and everything is dandy and
then you do an update right before commit - IF you then get U/Ps then you should
recompile/test again IMHO and perhaps study what came in.

Otherwise you run the risk of committing something that won't build. If the
update comes out clean then go ahead, nothing has changed since you last updated
so everything must be OK.

A nice sideeffect with running the update before commit is that you also see the
Ms and based on that you can more easily decide what to write in the commit
comment. It is quite common that you think you have only fixed bug X and when
you do the update you realize that, hey, I almost forgot - I also edited file Z
to fix that little buglet Y...

regards, Göran

PS. I am actually adding support for "P" in sqcvs - the CVS protocol
is capability based and if the client says "Nope, I can't handle patch
files" then those don't get sent by the server- no "P"s shows up. But that is a
good thing to be able to handle so I just added it actually... :-) The unified
diff is very easy to apply. DS

Göran Hultgren, gor...@bl...
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Bert F. <be...@is...>]

On Mon, 13 May 2002, Tim Rowledge wrote:

> In message <E17...@le...>
>           gor...@bl... wrote:
> 
> 
> > The update will tell you what files are modified "M" and that will be
> > committed.
> > You can also then see if other people have just committed stuff ("P"/"U"
> > etc) that you should take into account before committing.
> Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
> (when I managed to commit everybody's open files - I cn't imagine what
> the logical argument in favour of that working was) and couldn't find an
> explanation in any of my cvs doc (I have assorted webpages snarfed
> locally that I use).

Then you just don't use the right doc. It's mentioned in the info files as 
well as here, for example:
http://www.cvshome.org/docs/manual/cvs_16.html#SEC154

U The file was brought up to date with respect to the repository. 
P Like `U', but the CVS server sends a patch instead of an entire file
M The file is modified in your working directory.X
C A conflict was detected while trying to merge your changes

-- Bert

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Tim R. <ti...@su...>]

In message <E17...@le...>
          gor...@bl... wrote:


> The update will tell you what files are modified "M" and that will be
> committed.
> You can also then see if other people have just committed stuff ("P"/"U"
> etc) that you should take into account before committing.
Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
(when I managed to commit everybody's open files - I cn't imagine what
the logical argument in favour of that working was) and couldn't find an
explanation in any of my cvs doc (I have assorted webpages snarfed
locally that I use).

tim

-- 
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Useful random insult:- Even a two button mouse gives him too many options.

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

rwi...@at... wrote:
> Göran wrote:
> > Rob Withers <rwi...@at...> wrote:
> > > Do we know that we can restrict access to the main 
> trunk to the
> > > maintainers, then issue expanded rights to select 
> individuals to their
> > 
> > CVS has no such facility out-of-the-box AFAIK. But I 
> think a policy will
> > suffice.
> > After all, (IMHO) developers should only get 
> commit "rights" when we
> > "trust" them.
> 
> Gosh, I really like what I am hearing from Andreas and I 
> saw your other post regarding cvssupport.  It feels like 
> we are about 80% of the way there for controlling cvs in 
> our process.  Do we want to complicate it further, 
> technically, by trying to tackle cvssupport?

Honestly, no! :-) But we can check it out later.

> > > branches?  The original model we had discussed was 
> that the main trunk
> > > was the most volitile, and both experimental work 
> and stable releases
> > > (and it's patches) are managed as branches.  
> > 
> > The only difference as I can see is that we restrict 
> commit rights to
> > the trunk to the maintainers and at the same time 
> raise the bar for
> > those commits - they should be "stable" in some sense, 
> at least tested
> > and validated to work by the maintainers themselves. 
> So a checkout of
> > HEAD (the tip of the trunk) should get you a pretty 
> descent VM though it
> > has not gone through any "release testphase".
> 
> Yes, this is what I was thinking.   The unfortunate side-
> effect of a structural change, like the exports change, 
> is that is not all ports are migrated, and you are left 
> with some ports that stop compiling.  This kind of work 
> really should be done on branches, until all ports 
> support the new change, then merge them in.  I think 
> this is achievable once we all know how to branch and 
> merge.

Yes.

> > But as you say: When releases are made then we still 
> should create a
> > release branch on which we can apply fixes later on 
> (when the trunk has
> > moved forward). And any experimental work are done in 
> branches.
> 
> How far off are we to 3.2final?

No idea. ;-)

> > "cvs --help tag" gives:
> 
> Is it correct that tagging the trunk and branching are 
> two separate commands?  For instance, we have the latest 

Yes - the reason for tagging right before doing a branch is that
otherwise you will not have a tag to refer to when you need to refer to
the "root" of the branch. The branch tag itself refers to the tip of the
branch - NOT the root. And you will need this later when you do the
merge work.

> code from the trunk loaded and say we want to tag the 
> main for 3.2g, then I want to branch from there for 3.2g-
> experimental-protected-memory.  
> 
> to tag the main trunk:
> 
> cvs tag -c 3.2g

Yes.

> to branch from that tag:
> 
> cvs tag -b -c -r 3.2g 3.2g-experimental-protected-memory
>
> Is this right?

Yes, but the tag command tags exactly those revisions that you have in
your own working area. A good rule though is to call the branch tags
"XXX-branch" and the branch root tags "Root-of-XXX". Or something like
that. This is stuff I will write about in the policy doc.

Since you tagged those on the line above I assume you still have those
revisions :-) so the "-r 3.2g" is actually unnecessary (but correct).

There is also the command "rtag" that can tag stuff without having a
workingcopy but I never use that - I feel in more control with "tag".

> to checkout the branch:
> 
> cvs checkout -r 3.2g-experimental-protected-memory

Yes, this would check out the tip of the branch. This will place a so
called "sticky tag" on your files in your workingcopy so that all
operations from now on happen on the branch. Quite convenient. You can
also move an existing checked out trunk onto the branch by using:
cvs update -r 3.2g-experimental-protected-memory

This would have the same result as the checkout but with much less IO.
And moving it back to the trunk is done by clearing the sticky tag:

cvs update -A

> [snip cvs tag help]
> 
> > If you are on Unix then there
> > are a few UIs around - I am playing around myself with 
> LinCVS and tkcvs.
> 
> hmmm.  I should go take a look at those.  Which is 
> better?

My impression is that LinCVS is a poor clone of WinCVS/MacCVS (which are
pretty good by now). TkCVS looks interesting and has more advanced
features.

Then there are numerous others like Pharmacy (GNOME) etc. Haven't tried
them yet.

regards, Göran

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

rwi...@at... wrote:
[SNIP]
> > It still bothers me that I _could_ make modifications 
> to (say) the unix
> > tree but it appears that this can't be helped. Perhaps 
> a good line in
> > the policy document would be to state that you "Never, 
> NEVER do a 'cvs
> > commit' from the platforms directory but only from 
> your platform branch
> > (win32, unix, Mac, Acorn, Cross)". I've been using 
> this policy for me
> > already and so far it turns out to be a good practical 
> rule.
> 
> Heh.  This is what I did this morning for the changes, 
> but I had to re-checkout the toplevel to add 
> osExports.c.  Of course, I had done a 'cvs diff squeak', 
> first, to verify that I was only commiting the files I 
> had planned on commiting.

A good rule is to do a "cvs update" first on the same level that you
intend to commit.

The update will tell you what files are modified "M" and that will be
committed.
You can also then see if other people have just committed stuff ("P"/"U"
etc) that you should take into account before committing.

> Are the aliases I had defined in the CVSROOT/modules 
> file a good idea?  It may be better to checkout the 
> explicit subtrees (Cross and unix in my case).

No, they are fine IMO. 

regards, Göran

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<rwi...@at...>]

Göran wrote:
> Rob Withers <rwi...@at...> wrote:
> > Do we know that we can restrict access to the main 
trunk to the
> > maintainers, then issue expanded rights to select 
individuals to their
> 
> CVS has no such facility out-of-the-box AFAIK. But I 
think a policy will
> suffice.
> After all, (IMHO) developers should only get 
commit "rights" when we
> "trust" them.

Gosh, I really like what I am hearing from Andreas and I 
saw your other post regarding cvssupport.  It feels like 
we are about 80% of the way there for controlling cvs in 
our process.  Do we want to complicate it further, 
technically, by trying to tackle cvssupport?

> > branches?  The original model we had discussed was 
that the main trunk
> > was the most volitile, and both experimental work 
and stable releases
> > (and it's patches) are managed as branches.  
> 
> The only difference as I can see is that we restrict 
commit rights to
> the trunk to the maintainers and at the same time 
raise the bar for
> those commits - they should be "stable" in some sense, 
at least tested
> and validated to work by the maintainers themselves. 
So a checkout of
> HEAD (the tip of the trunk) should get you a pretty 
descent VM though it
> has not gone through any "release testphase".

Yes, this is what I was thinking.   The unfortunate side-
effect of a structural change, like the exports change, 
is that is not all ports are migrated, and you are left 
with some ports that stop compiling.  This kind of work 
really should be done on branches, until all ports 
support the new change, then merge them in.  I think 
this is achievable once we all know how to branch and 
merge.

> But as you say: When releases are made then we still 
should create a
> release branch on which we can apply fixes later on 
(when the trunk has
> moved forward). And any experimental work are done in 
branches.

How far off are we to 3.2final?
 

> "cvs --help tag" gives:

Is it correct that tagging the trunk and branching are 
two separate commands?  For instance, we have the latest 
code from the trunk loaded and say we want to tag the 
main for 3.2g, then I want to branch from there for 3.2g-
experimental-protected-memory.  

to tag the main trunk:

cvs tag -c 3.2g

to branch from that tag:

cvs tag -b -c -r 3.2g 3.2g-experimental-protected-memory

Is this right?

to checkout the branch:

cvs checkout -r 3.2g-experimental-protected-memory


[snip cvs tag help]

> If you are on Unix then there
> are a few UIs around - I am playing around myself with 
LinCVS and tkcvs.

hmmm.  I should go take a look at those.  Which is 
better?

> 
> regards, Göran
> 

Cheers,
Rob

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<rwi...@at...>]

> Rob,
> 
> > Do we know that we can restrict access to the main 
trunk to the
> > maintainers, then issue expanded rights to select 
individuals to their
> > branches?  The original model we had discussed was 
that the main trunk
> > was the most volitile, and both experimental work 
and stable releases
> > (and it's patches) are managed as branches.
> > 
> > What are the user access controls available to us 
from SF?
> 
> None as far as I know. If you have developer status 
you have commit
> rights anywhere (I think they've never anticipated 
that kind of strict
> distinction that we're discussing here - perhaps it 
might be worthwhile
> to send them a note explaining why we think along 
these lines).
> 
> BTW, I've been thinking about the issue of (either 
accidentally or
> non-accidentally) making "mistakes" but (in hindsight) 
I really don't
> think this is going to be a problem. For one thing, we 
_all_ make
> mistakes at times (just remember this fundamentally 
flawed ClassBuilder
> CS recently), CVS can deal with many of the problems 
in a reasonably
> straightforward way, and I also don't think the VM 
developer community
> would tolerate any non-agreeable behavior that would 
put the stability
> of Squeak on _any_ platform at risk. The last line of 
defense is having
> project admin status which (as far as I am aware) all 
of the primary
> maintainers have. 

Andreas, Hurray!  That sounds very reasonable and 
balanced between stability/reliability and openness.  We 
can take advantage of all the volunteers, yet ensure a 
level of quality and hopefully minimize flux/thrash.  

I messed up this process this morning, in fact.  The 
problem wasn't that I committed to the main branch, 
because *nix wasn't compilable with VMMaker32-7.5 and we 
are still at the pre-integration stage wrt Ian's code.  
The problem was that I didn't inform Lex and this dist 
list that I was doing the work.  

> 
> It still bothers me that I _could_ make modifications 
to (say) the unix
> tree but it appears that this can't be helped. Perhaps 
a good line in
> the policy document would be to state that you "Never, 
NEVER do a 'cvs
> commit' from the platforms directory but only from 
your platform branch
> (win32, unix, Mac, Acorn, Cross)". I've been using 
this policy for me
> already and so far it turns out to be a good practical 
rule.

Heh.  This is what I did this morning for the changes, 
but I had to re-checkout the toplevel to add 
osExports.c.  Of course, I had done a 'cvs diff squeak', 
first, to verify that I was only commiting the files I 
had planned on commiting.

Are the aliases I had defined in the CVSROOT/modules 
file a good idea?  It may be better to checkout the 
explicit subtrees (Cross and unix in my case).

Cheers,
Rob

PS.  I am posting through the web for the first time, 
since I am at work.  I may be too busy later, to post 
immediately.

[Squeak-VMdev] Developers @ source forge

[Andreas R. <And...@gm...>]

Folks,

Since it seems that we're really making some progress with the VM stuff
at source forge I'd like to raise one additional issue. It's the
question who should be a developer (e.g., have commit rights) and how
some person could become one. Looking at the list we have 18 developers
some of which I don't even know. This will be an ongoing problem and I'd
like to make a small proposal here:

Since we can't know every last person we have to put our trust in the
persons we do know and trust enough to have write access. I'd like to
see a "vouching" scheme where any developer in the Squeak project needs
a vouch by at least one other developer. This vouch implies a certain
indirect responsibility - in other words, if the person who you vouched
for misbehaves you are responsible for a) making sure he or she behaves
according to the policies and b) cleaning up for this person's mess in
case he or she doesn't. You can remove your vouch if you no longer trust
this person's ability to handle things properly. A developer without a
vouch will be automatically removed from the list. So will any
"disconnected" networks of vouches. In even other words, the vouches
represent "pointers to developers" and anyone who isn't pointed to will
be garbage collected ;-) The roots of that system are the primary
developers for each port.

For anyone who wants to join the developers he or she needs a vouch by
an existing developer. The existing developer is responsible for
explaining the policies and rules on VMDev. The existing developer can
also ask one of the people having vouched for him to give the new
developer write access. Once you're at the roots of that system you will
end up with a project admin who will be able to make the necessary
modifications. It also means that people who have been vouched for by
project admins have a "shorter path" to getting new people in than
developers who are only connected through "three indirect links" (of
course, if you can get a project admin to vouch for you directly, that's
the easiest way). This models the trust level which weakens with any new
indirection. It also means that any developer shoud try to get a vouch
from the roots, e.g., proove to one the primary maintainers that he or
she is a worthwhile addition to the Squeak VMDev community.

Here are the people on the developers list I can vouch for:

* Bert Freudenberg
* Cees de Groot
* G=F6ran Hultgren
* Ian Piumarta
* John McIntosh
* Lex Spoon
* Michael R=FCger
* Tim Rowledge
* Rob Withers

[Note that I have included the primary developers (roots) to indicate
that my trust in their abilities].=20

What do you think?

Cheers,
  - Andreas

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

"Andreas Raab" <And...@gm...> wrote:
> Rob,
> 
> > Do we know that we can restrict access to the main trunk to the
> > maintainers, then issue expanded rights to select individuals to their
> > branches?  The original model we had discussed was that the main trunk
> > was the most volitile, and both experimental work and stable releases
> > (and it's patches) are managed as branches.
> > 
> > What are the user access controls available to us from SF?
> 
> None as far as I know. If you have developer status you have commit
> rights anywhere (I think they've never anticipated that kind of strict
> distinction that we're discussing here - perhaps it might be worthwhile
> to send them a note explaining why we think along these lines).

Well, I would guess SF just uses CVS more or less off the shelf but
anyway, this might help:
https://sourceforge.net/projects/cvssupport/ 

According to some postings on Usenet it includes ACL functionality.

regards, Göran

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

Rob Withers <rwi...@at...> wrote:
> "Andreas Raab" <And...@gm...> wrote:
> > Let's see if I got you right: You are basically proposing that there's a
> > main trunk in the repository which is guarded by the maintainer of the
> > port. Everyone else having commit permissions can happily hack away on
> > his or her branch. Merging works by a variety of models depending on
> > who's got what amount of time. Correct?!
> 
> Do we know that we can restrict access to the main trunk to the
> maintainers, then issue expanded rights to select individuals to their

CVS has no such facility out-of-the-box AFAIK. But I think a policy will
suffice.
After all, (IMHO) developers should only get commit "rights" when we
"trust" them.

> branches?  The original model we had discussed was that the main trunk
> was the most volitile, and both experimental work and stable releases
> (and it's patches) are managed as branches.  

The only difference as I can see is that we restrict commit rights to
the trunk to the maintainers and at the same time raise the bar for
those commits - they should be "stable" in some sense, at least tested
and validated to work by the maintainers themselves. So a checkout of
HEAD (the tip of the trunk) should get you a pretty descent VM though it
has not gone through any "release testphase".

But as you say: When releases are made then we still should create a
release branch on which we can apply fixes later on (when the trunk has
moved forward). And any experimental work are done in branches.

> What are the user access controls available to us from SF?

I haven't checked.
 
> > There are a few points about this that I'm a bit unhappy with. One is
> > that it appears to me that working on a branch may be complicated. 
> 
> I have forgotten the commands to tag the trunk, then branch (with a
> branch tag).  It really isn't that difficult once we know these
> commands.

"cvs --help tag" gives:

Usage: cvs tag [-bcdFflR] [-r rev|-D date] tag [files...]
        -b      Make the tag a "branch" tag, allowing concurrent
development.
        -c      Check that working files are unmodified.
        -d      Delete the given tag.
        -F      Move tag if it already exists.
        -f      Force a head revision match if tag/date not found.
        -l      Local directory only, not recursive.
        -R      Process directories recursively.
        -r rev  Existing revision/tag.
        -D      Existing date.
(Specify the --help global option for a list of other help options)

So tagging the trunk is done by (since -R is default) cd'ing to the top
directory in your workingcopy containing the revisions (a checked out
trunk) that you want to tag (the tag command tags the revisions that YOU
have in your workingcopy so you don't need to worry if someone else has
just committed something):

cvs tag MYLITTLETAG

Just add a "-b" to create a branch at this point (which technically is
just a special kind of tag). WinCVS/MacCVS has a little dialog for this
of course.

Btw - WinCVS and MacCVS are pretty nice and they are only "wrappers"
around the cvs executable so they are no less safe to use than CLI cvs.
So, if you are on Win32 or Mac - use them. If you are on Unix then there
are a few UIs around - I am playing around myself with LinCVS and tkcvs.
There are also others and I think that all of them except for a Java
implementation I don't know the name of, are wrappers around the cvs
executable. 

Sidenote: This means that there aren't that many OpenSource pserver
protocol implementations out there AFAICT. The CVS original, sqcvs and
the Java implementation are the ones I know of. Oh yes, and one special
for VAJ that we used a while ago.

> Rob

regards, Göran

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Andreas R. <And...@gm...>]

Rob,

> Do we know that we can restrict access to the main trunk to the
> maintainers, then issue expanded rights to select individuals to their
> branches?  The original model we had discussed was that the main trunk
> was the most volitile, and both experimental work and stable releases
> (and it's patches) are managed as branches.
> 
> What are the user access controls available to us from SF?

None as far as I know. If you have developer status you have commit
rights anywhere (I think they've never anticipated that kind of strict
distinction that we're discussing here - perhaps it might be worthwhile
to send them a note explaining why we think along these lines).

BTW, I've been thinking about the issue of (either accidentally or
non-accidentally) making "mistakes" but (in hindsight) I really don't
think this is going to be a problem. For one thing, we _all_ make
mistakes at times (just remember this fundamentally flawed ClassBuilder
CS recently), CVS can deal with many of the problems in a reasonably
straightforward way, and I also don't think the VM developer community
would tolerate any non-agreeable behavior that would put the stability
of Squeak on _any_ platform at risk. The last line of defense is having
project admin status which (as far as I am aware) all of the primary
maintainers have. 

It still bothers me that I _could_ make modifications to (say) the unix
tree but it appears that this can't be helped. Perhaps a good line in
the policy document would be to state that you "Never, NEVER do a 'cvs
commit' from the platforms directory but only from your platform branch
(win32, unix, Mac, Acorn, Cross)". I've been using this policy for me
already and so far it turns out to be a good practical rule.

Cheers,
  - Andreas

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Andreas R. <And...@gm...>]

G=F6ran,

Thanks for all the info. So I'd say I'm in for this model at least for
the time being. We'll have to figure out more while it develops but it
seems like a reasonable starting point for me.

Cheers,
  - Andreas

> -----Original Message-----
> From: gor...@bl... [mailto:gor...@bl...]=20
> Sent: Monday, May 13, 2002 5:06 PM
> To: Andreas Raab
> Cc: squ...@li...
> Subject: RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @=20
> sourceforge
>=20
>=20
> "Andreas Raab" <And...@gm...> wrote:
> > G=F6ran,
> >=20
> > > Hmmm, somewhere here it feels like I have missed some posting - I
> > > thought I was waiting for some feedback from you Andreas? :-)
> > > I am referring to my post beginning with the line "Long mail=20
> > > about CVS, branches, tags etc.".
> >=20
> > That's to a large extent because I'm still digesting what you wrote.
>=20
> Ok. :-) Hope it wasn't too whimsical.
>=20
> > Mind you, I'm no expert at CVS so it somewhat escapes me what a good
> > model for working in it could be (and that's also why I'm=20
> trying to take
> > you up on the your offer to write something up on it ;-)
>=20
> The book I referenced is IMHO a good buy. But sure, if we can come up
> with a model then I will write the "manual".
>=20
> > Let's see if I got you right: You are basically proposing=20
> that there's a
> > main trunk in the repository which is guarded by the=20
> maintainer of the
> > port. Everyone else having commit permissions can happily=20
> hack away on
>=20
> Yes. Probably we will not bother with trying to ensure that noone else
> commits on the trunk, but hey - if you abuse your given=20
> "commit rights"
> then people will get angry, so I don't think anyone will do=20
> that. A good
> simple "policy" document will suffice.
>=20
> > his or her branch. Merging works by a variety of models depending on
> > who's got what amount of time. Correct?!
>=20
> Yes.
>=20
> > There are a few points about this that I'm a bit unhappy=20
> with. One is
> > that it appears to me that working on a branch may be=20
> complicated. We
>=20
> I don't think it will be that complicated. If we disregard=20
> merging then
> there is no difference whatsoever, the only thing you do is add a "-r
> tag" when doing the checkout. Then your workingcopy "knows"=20
> it's on the
> branch so all operations from then on is just like as if it was on the
> trunk.
>=20
> The only thing people on branches need to be aware of is that they
> should tag here and there and write good commit comments in order to
> make the mergework easier, but that is "common sense". So...
> "complicated"? Naah. ;-)
>=20
> One obvious branch would be an unofficial "bugfix" branch on a release
> (there should also be an official releasebranch as I have been saying
> over and over by now). Lex, Bob and others are pretty fast on fixing
> bugs etc on the Unix port and they would typically use such a=20
> branch to
> get their fixes in quick and easy. Since the branch only contains
> bugfixes (no new features etc) and it is rooted at a release=20
> it will be
> trivial for Ian - when he feels like it - to merge that stuff=20
> down into
> the release, look it over, try it out and when he is=20
> satisifed - commit
> it on the official release branch. Then he would of course=20
> also have to
> merge it into the trunk too, but for bugfixes (that tend to be rather
> small and local) it will probably be quite easy.
>=20
> > might argue that this is the price a person has to pay in=20
> order to get
> > write permission at SF but if so, we should all agree on it. Please
> > vote.
>=20
> Since it seems that people want some form of "process" that filters
> stuff through a couple of official maintainers then I think this model
> is fine. It may not be as most projects work, but not that different
> either I think.
>=20
> > Secondly, I don't understand why somebody who wants to=20
> branch would need
> > to ask for permission to do so. After all, the main branch=20
> is unaffected
> > by this change, isn't it?! What am I missing?!
>=20
> You are not missing anything. Technically noone would need to ask for
> permission and perhaps we can skip that part as long as we make sure
> (policy document again) that the branches are documented in a
> branches.txt file on SF (better than the almighty swiki -=20
> this way it is
> easy to see when it changes etc).
>=20
> Yes, the trunk is unaffected. The only thing I want to avoid is
> everybody creating branches to left and right... But that is probably
> prevented by saying a few words about it in the policy document.
>=20
> > Thirdly, we may consider making up "new ports" instead of=20
> "long-living
> > branches". After all, some of the work that might be=20
> considered a branch
> > (since it has the same target platform) is rather an=20
> independent port.
> > Such as, for example, PhiHo's Mob VM. It shares a few files but it
> > appears to me that it is a separate port rather than a branch.
>=20
> Agree.
>=20
> > Cheers,
> >   - Andreas
>=20
> Cheers, G=F6ran
>=20

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

"Andreas Raab" <And...@gm...> wrote:
> Göran,
> 
> > Hmmm, somewhere here it feels like I have missed some posting - I
> > thought I was waiting for some feedback from you Andreas? :-)
> > I am referring to my post beginning with the line "Long mail 
> > about CVS, branches, tags etc.".
> 
> That's to a large extent because I'm still digesting what you wrote.

Ok. :-) Hope it wasn't too whimsical.

> Mind you, I'm no expert at CVS so it somewhat escapes me what a good
> model for working in it could be (and that's also why I'm trying to take
> you up on the your offer to write something up on it ;-)

The book I referenced is IMHO a good buy. But sure, if we can come up
with a model then I will write the "manual".

> Let's see if I got you right: You are basically proposing that there's a
> main trunk in the repository which is guarded by the maintainer of the
> port. Everyone else having commit permissions can happily hack away on

Yes. Probably we will not bother with trying to ensure that noone else
commits on the trunk, but hey - if you abuse your given "commit rights"
then people will get angry, so I don't think anyone will do that. A good
simple "policy" document will suffice.

> his or her branch. Merging works by a variety of models depending on
> who's got what amount of time. Correct?!

Yes.

> There are a few points about this that I'm a bit unhappy with. One is
> that it appears to me that working on a branch may be complicated. We

I don't think it will be that complicated. If we disregard merging then
there is no difference whatsoever, the only thing you do is add a "-r
tag" when doing the checkout. Then your workingcopy "knows" it's on the
branch so all operations from then on is just like as if it was on the
trunk.

The only thing people on branches need to be aware of is that they
should tag here and there and write good commit comments in order to
make the mergework easier, but that is "common sense". So...
"complicated"? Naah. ;-)

One obvious branch would be an unofficial "bugfix" branch on a release
(there should also be an official releasebranch as I have been saying
over and over by now). Lex, Bob and others are pretty fast on fixing
bugs etc on the Unix port and they would typically use such a branch to
get their fixes in quick and easy. Since the branch only contains
bugfixes (no new features etc) and it is rooted at a release it will be
trivial for Ian - when he feels like it - to merge that stuff down into
the release, look it over, try it out and when he is satisifed - commit
it on the official release branch. Then he would of course also have to
merge it into the trunk too, but for bugfixes (that tend to be rather
small and local) it will probably be quite easy.

> might argue that this is the price a person has to pay in order to get
> write permission at SF but if so, we should all agree on it. Please
> vote.

Since it seems that people want some form of "process" that filters
stuff through a couple of official maintainers then I think this model
is fine. It may not be as most projects work, but not that different
either I think.

> Secondly, I don't understand why somebody who wants to branch would need
> to ask for permission to do so. After all, the main branch is unaffected
> by this change, isn't it?! What am I missing?!

You are not missing anything. Technically noone would need to ask for
permission and perhaps we can skip that part as long as we make sure
(policy document again) that the branches are documented in a
branches.txt file on SF (better than the almighty swiki - this way it is
easy to see when it changes etc).

Yes, the trunk is unaffected. The only thing I want to avoid is
everybody creating branches to left and right... But that is probably
prevented by saying a few words about it in the policy document.

> Thirdly, we may consider making up "new ports" instead of "long-living
> branches". After all, some of the work that might be considered a branch
> (since it has the same target platform) is rather an independent port.
> Such as, for example, PhiHo's Mob VM. It shares a few files but it
> appears to me that it is a separate port rather than a branch.

Agree.

> Cheers,
>   - Andreas

Cheers, Göran

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Rob W. <rwi...@at...>]

"Andreas Raab" <And...@gm...> wrote:
> Let's see if I got you right: You are basically proposing that there's a
> main trunk in the repository which is guarded by the maintainer of the
> port. Everyone else having commit permissions can happily hack away on
> his or her branch. Merging works by a variety of models depending on
> who's got what amount of time. Correct?!

Do we know that we can restrict access to the main trunk to the
maintainers, then issue expanded rights to select individuals to their
branches?  The original model we had discussed was that the main trunk
was the most volitile, and both experimental work and stable releases
(and it's patches) are managed as branches.  

What are the user access controls available to us from SF?

> 
> There are a few points about this that I'm a bit unhappy with. One is
> that it appears to me that working on a branch may be complicated. 

I have forgotten the commands to tag the trunk, then branch (with a
branch tag).  It really isn't that difficult once we know these
commands.

Rob

RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[Andreas R. <And...@gm...>]

G=F6ran,

> Hmmm, somewhere here it feels like I have missed some posting - I
> thought I was waiting for some feedback from you Andreas? :-)
> I am referring to my post beginning with the line "Long mail=20
> about CVS, branches, tags etc.".

That's to a large extent because I'm still digesting what you wrote.
Mind you, I'm no expert at CVS so it somewhat escapes me what a good
model for working in it could be (and that's also why I'm trying to take
you up on the your offer to write something up on it ;-)

Let's see if I got you right: You are basically proposing that there's a
main trunk in the repository which is guarded by the maintainer of the
port. Everyone else having commit permissions can happily hack away on
his or her branch. Merging works by a variety of models depending on
who's got what amount of time. Correct?!

There are a few points about this that I'm a bit unhappy with. One is
that it appears to me that working on a branch may be complicated. We
might argue that this is the price a person has to pay in order to get
write permission at SF but if so, we should all agree on it. Please
vote.

Secondly, I don't understand why somebody who wants to branch would need
to ask for permission to do so. After all, the main branch is unaffected
by this change, isn't it?! What am I missing?!

Thirdly, we may consider making up "new ports" instead of "long-living
branches". After all, some of the work that might be considered a branch
(since it has the same target platform) is rather an independent port.
Such as, for example, PhiHo's Mob VM. It shares a few files but it
appears to me that it is a separate port rather than a branch.

Cheers,
  - Andreas

[Squeak-VMdev] [vmdev] Updated unix with the latest changes needed by VMMaker32-7.5

[Rob W. <rwi...@at...>]

I wasn't able to compile internal or external this weekend, so I fixed
it per Tim's intructions.  I didn't see the commit emails get sent, so
here is what I did:

- added osExports.c based from the RiscOS version.  Added the exports
for the browser plugin functions.  Bert, you may want to verify that
this builds for you
- removed platform.exports
- changed squeak/platforms/unix/misc/util/mkMake to use
SQUEAK_BUILTIN_PLUGIN defines for internal plugins.  Removed reference
to platform.exports as a basename
- changed squeak/platforms/unix/plugins/Mpeg3Plugin/mkMakeRules to use
SQUEAK_BUILTIN_PLUGIN define for internal mode

I tested from a clean checkout and it all looks well.

cheers,
Rob

[Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

Ok, list open? : -)
From: gor...@bl...

I wrote:
> This is of course a timelimited offer - say 7 days - that depends on the fact
> that we can agree on a model. ;-) Currently I am waiting for a response from
> Andreas on the other questions/stuff that he was pondering...

Well, it looks to me that 6 days have gone by... You better run for it
guys!

regards, Göran

[Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge

[<gor...@bl...>]

"Andreas Raab" <And...@gm...> wrote:
> Göran,
> 
> > Tell you what - if we can agree on a model as the ones 
> > discussed here (branches, tags, releases, permissions)
> > then I can offer to write (with your feedback of course)
> > a short but concise howto/rulebook for command line CVS and
> > WinCVS/MacCVS on the Swiki.
> 
> I'll take you on that ;-) So let's talk about the recommended model
> since that's still not entirely clear to me. Can somebody perhaps try to

Hmmm, somewhere here it feels like I have missed some posting - I
thought I was waiting for some feedback from you Andreas? :-)
I am referring to my post beginning with the line "Long mail about CVS,
branches, tags etc.".

> outline how the line of development looks like given that:
> a) we have a few "primary" maintainers for any given platform
> b) somebody wants to add a "patch" or so (just had two requests on this)
> c) somebofy wants to start off with an experimental version (like the BC
> stuff)
> d) the primary maintainers will want to merge those modifications at a
> later point.
> 
> What I'm interested in here is what we think this "should" look like.

Ok, since I have also posted quite a long post recently and haven't
really given anyone a chance to reply, I will try to make this one
brief. Trying to answer:

a) (well, that was not a question I think)

b) Somebody wants to add a patch:

Well, if it is sent/posted as a patchfile then it will just be up to the
maintainer to apply that patch to his/her workingcopy, test it and
commit it if it looks good. Since (given the proposed model) the
maintainer works on the trunk it's just a trivial commit.

c) Somebody wants to branch. Fine, anyone with "commit permission" on SF
will likely be a trusted person (I mean, we have given him/her commit
permission right?) so we can probably assume he/she has read our
policydocument (to be written) and that he/she "asks publically for
permission" before doing the branch. Then if noone objects I would
assume say it is fine for him/her to branch. The branch operation will
be done by him/herself. The policy document will describe how to do it
and how to tag before branching etc. (God, that he/she is really
tiresome... I will stick to he for simplicity! :-)

d) Ok, Joe (the developer that did the branch) has fixed some pretty
cool Win32 stuff on his branch and he alerts Andreas to this fact. Since
the branch the trunk has moved forward. A few scenarios:

-Andreas has plenty of time this weekend so he says to Joe "Cool, I will
make the merge myself". And then he sits down and follows the
instructions in the policy document how to do a full (=all changes that
have been made on the branch) merge from a branch to the trunk.
Technically it is quite easy but since the trunk has moved forward he
needs to review the changes and resolve any conflicts. Since this is a
full merge of the branch the branch should not really be used anymore,
it is better for Joe to create a new branch from the trunk if he wants
to continue working on a branch of his own.

-Andreas says "Ok, Joe, I don't have time for this - produce patchfiles
for me for feature X and Y, I don't want the rest". And the rest is like
b) above.

-Andreas says "Ok, Joe, how do I merge?". Joe says "Well, first I did
the X feature up to tag XXXX-done. And then I did the Y feature up to
tag YYYY-done. You can merge them one at a time. Then after YYYY-done I
have been trying out Mega-Feature Z but it is only halfbaked and doesn't
work so don't go there.". Andreas then follows instructions in policy
document about how to merge repeatedly from a branch to the trunk and
does this in two steps. He leaves out the stuff from YYYY-done and
forward.

To make things a bit simpler and to "force" the branches to be kept
"short" I would propose that we don't merge from the trunk into the
branches - we only merge stuff from the branches into the trunk. This
means that the branch will move further and further away from the trunk.
If we merge in both directions it is trickier, more work and would
perhaps increase the risk of getting "longlived branches". Since the
branch won't get any new stuff that goes into the trunk this will
encourage the branch owners to merge with the trunk so that they can
"rebranch" from the trunk and get the latest/greates from there.

> Cheers,
>   - Andreas

Cheers, Göran

PS. "Brief" my ass^H^H^Hbehind. :-) DS

[Squeak-VMdev] Re: Trouble building 3.3 VM (modules)

[Bert F. <be...@is...>]

On Sat, 11 May 2002, Andreas Raab wrote:

> [Note: I would've posted this to the SF list but I don't know if the
> relevant people are already subscribed - for some strange reason the
> subscriber list is only visible to the list admin (which I am not). Why
> this supercautius policy?! I don't think we'll get spammed by a
> subscriber on _that_ list. Anyways...]

I just did not change the default, which seems to be set to "maximum 
paranoia". Fixed now. I set it to "everyone can view" - if anyone objects, 
I can easily set it to "subscribers only".

I took the freedom to subscribe you all - at least until it wouldn't let 
me anymore (hence still some Cc:'s). But I think we can continue the 
discussion at the list now.

-- Bert