[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