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