internal or external, that is the question
andreas.raab at gmx.de
Sun Aug 28 21:10:35 UTC 2005
Brad Fuller wrote:
> Andreas Raab wrote:
>> Different groups have different styles of work and we (the VM
>> maintainers) have long adopted a style which does not assume that HEAD
>> is always the latest stable version but rather provide explicit file
>> releases. The main reasons being that there is no conceptual
>> difference between checking out HEAD or using a stable file release
>> and to allow us to move forward so that we know the order in which
>> pending changes get integrated. This is in particular important since
>> the main ports have maintainers with very different schedules and
>> requiring everyone to get in sync before allowing to make a change to
>> the trunk would probably deadlock the entire group.
> That's what branches are for, right?
It depends on how you look at it. I see HEAD as the head of the
main-line development. Branches are for trying out orthogonal stuff
which will not necessarily go into main line. It's a different model
from what you are describing where all development happens in branches
and commits to the trunk happen rarely. I have seen both in practice and
there is not much difference.
>> For Windows, no. I still haven't gotten around to update the VM
>> sources to 3.8 - in other words if we would follow your proposed model
>> the trunk would be stuck at 3.7 which I would find an extremely
>> unpleasant situation.
> Exactly, the trunk would be the stable version. I guess I don't see why
> it's better to have the bleeding edge in the trunk.
Ah, I think I see what you are missing: You assume that the different
platforms are independent of each other, e.g., that the trunk of the SVN
repository could have a stable 3.7 Windows *and* a stable 3.8 Mac set of
Unfortunately, that is not true. There are overlaps between the
platforms (mostly in the Cross tree) and if there are conflicting
changes (there typically are) you cannot have your cake and eat it, too.
The only alternative is to either accept that some platforms may be
broken at HEAD (the solution we adopted) or to delay any commits to the
trunk until *all* platforms are updated.
And the latter is probably impossible - maintaining a port is very
specific stuff and I couldn't even dream of fixing an issue in the Mac
or the Risc OS support code (the same probably goes the other way
around). So unless you have a set of maintainers who can jump at the
blink of an eye 24/7 you better deal with the fact that one of them
might just be off for vacation.
> If it sounds messy because of all the different platforms, maybe the
> released should be located one more dir below for each platform. Or,
> separate trunks for each platform. At least the source would be in one
This might be doable but it sounds like quite a bit of work and I
suppose you aren't volunteering...
>> Also, the set of maintainers has been working together in some form or
>> other for almost ten years now and you should at least consider the
>> possibility that there are reasons for why things are the way they are.
> Oh, I do. I just question it, that's all.
Yes, I know. We see these questions every other year usually in the form
of some demands that "you must organize your work like this" and of
course, with absolutely no intent to help and actually improve things.
I've gotten edgy about this over the years to the point that I've
considered twice to just drop it and leave you guys doing whatever you
think you can do better (who knows, maybe you can).
>> They work for us. And If you think we're all morons who don't know
>> Jack you are of course free to set up an alternative repository and
>> show the superiority of your ways. We'll discuss the results in 2015 ;-)
> I understand and respect that they've been working together for a long
> time. I'm indebted to their invaluable contributions. I just want to be
> able to obtain those contributions and build it in a reasonable way.
> And, I didn't mean to imply that the maintainers are morons.
Sorry, that was meant as a joke about short-term vs. lasting impact.
> Poking around, I see that there are indeed branches and tags, but they
> seem a bit backward to me. There is a 3.7 branch for unix at:
> http://squeak.hpl.hp.com/svn/squeak/branches/unix-3.7-7/. Would this be
> the released 3.7 for unix?
Good question. As you may or may not know, dealing with branches in CVS
is a pain and so we essentially didn't use it. This might just be legacy
from the CVS days or it might be something different. Only VM-dev could
> There are several places in the swiki that states to go to the trunk for
> the sources. In one place, it does say "the latest sources". So, you got
> me there. Ok, how about we clean up the swiki, so that it indicates
> where to get the stable or released sources... to save headaches for the
> next bloke.
That's the problem with the Swiki - some people just edit something and
there is absolutely no authority to what they say. The only place that
counts for Unix is http://squeak.hpl.hp.com/unix.
> Poking around some more, I see that there is a page that indicates where
> to get the win sources. To me, it seems a bit backwards to have people
> go to different places for sources. Isn't it a goal for squeak to
> maintain consistency among all platforms? It's not possible completely,
> of course, but that's the goal. So, it seems a waste (to me, no offense
> intended) to not use SVN to it's full potential.
And the only place that's authorative for windows is
http://minnow.cc.gatech.edu/squeak/3272 (where it points back to
More information about the Vm-dev