Brian Rice wrote:
> On Mar 10, 2007, at 5:51 PM, Andreas Raab wrote:
>> Which, if you start a new platform branch instead of trying to patch 
>> existing ones, shouldn't be a problem I think.
> 
> This sounds promising, but most of us with interest in handhelds aren't 
> experienced (Squeak) VM hackers, and are not aware of the process 
> involved, especially if we are making relatively slight tweaks to a 
> mature branch, like the Unix branch for the Zaurus PDA or Nokia internet 
> tablets. In a lot of these cases, it's a configuration issue, and the 
> way to make a platform branch that is maintainable is not clear.

I agree. But a large part of making such tweaks in a separate platform 
branch is to spend a bit of time to learn the (admittedly imperfect) 
build structure. I think we all agree that it's imperfect but it's the 
best we could come up with so far, so willingness to learn it and live 
inside it is a must if you want to take on this task seriously.

> Most of 
> the existing ports are currently just tarballs of some modified snapshot 
> of the VM sources from a while ago, so it seems like people have found 
> it easiest so far to just hack until it worked and then archive for 
> posterity.

That may well be. How would you propose to change that? As far as I can 
remember over the history of Squeak, this is how all ports started. The 
main difference between those at SqueakVM.org and those not is that some 
of them were supported over a period of time, and some of them weren't. 
If you make a one-shot solution, there is not much value in bringing 
into the common build structure at SqueakVM.org. If you spend a longer 
time it starts to make a lot more sense.

> As a non-handheld, but practical example, there have been 
> (mostly-working, but now no longer on the 'net) BeOS ports of some 
> versions of the VM, but it's never gotten to the point where those ports 
> met the main repositories. That's an example of a port whose solution 
> might tell the solver what documentation needs to be available to 
> complete other such ports. Making one solution tractable would make the 
> solution of the handheld problems nearly as tractable.

I'm trying to be serious here but do you really expect the port 
maintainers to go hunting for unsupported ports, and fold them into the 
common build structure? I think that's a bit of an expectation mismatch. 
The people who maintain "their" ports do it *precisely* because they 
like their platform. If you like BeOS, and want to add it to the common 
build structure and maintain it, please go for it! But asking other 
people to maintain ports in which they basically have no interest seems 
a bit far fetched.

> Another thing occurs to me: one of the factors that makes coordinating 
> Squeak VM development for PDAs is that there are many toolchains (even 
> if gcc-based) for these different systems, and some are proprietary 
> (MSVC), so no one person will likely be able to understand or vet all 
> the ports (especially Ian or you, who have many things on your plates).

But this is exactly why we have platform branches to begin with. WinCE 
for example - a long time ago we had a separate port for WinCE, which I 
folded into the main Win32 port around 1998 or so. Later it turned out 
to be unfeasible simply because CE was missing so many features that you 
take for granted on Win32 in general and these ports again split. Today, 
the "main" win32 port is built with a setup that is specifically 
available on SqueakVM.org (only FOSS build tools btw, so *everyone* can 
build that VM) and the last versions of WinCE were being built with an 
MS proprietary toolset. Fine with me, and worth a separate platform 
branch as far as I am concerned. OTOH, I just asked Eliot if he could 
make the VC++ makefiles for the main Win32 port available since he's 
just been working on this. Both are fine ways to deal with it and I am 
open to either one.

> So, here are the questions that occur to me:
> 
> - Is there a guide for how to do this?

To do what exactly? Make a "minor port" that leverages a "major" port 
and just tweaks it slightly? I would guess that depends on how much 
magic you do with your build setup. For example, the current win32 build 
looks for files first in the win32 tree, then in the cross tree. For a 
"minor" port to leverage this it would be quite doable to have a build 
setup that first looks in, say "WinCE", then "Win32", then "Cross" etc. 
It is some work, sure, and it may require some communication with the 
"main" port but it's definitely doable.

> - If you do find it easy enough to explain in an email, how can we put 
> it on an official Squeak site where it is likely to be found? (The wiki 
> is great, or a README in the SVN tree, but there should at least be a 
> link from squeakvm.org's page or something.)

I don't quite understand what you mean here. PR is not my main task ;-)

> - What is the recommended process for submitting patches for such a 
> branch when the level of interaction isn't high enough to merit asking 
> for write access to the SVN server?

Maintaining a platform port *is* worth asking for write access. And like 
I said before, I wouldn't expect that to be any problem whatsoever. If 
you have patches for a port, post them to vm-dev.

> - If a permanent account to the SVN server is justified, how does one 
> make that request?

Starting with the work you've already done (e.g., at least some partial 
work result to show you are serious about it) sending a nice request to 
Ian (he owns the physical box) with CC: to vm-dev would be all that is 
needed. If nothing happens in a couple of weeks (sometimes people are 
just busy) follow up on vm-dev.

> This kind of information should be published in an obvious place rather 
> than repeated on email.

Like I was saying before, I don't own the PR on VM stuff. Knock yourself 
out if you like, in fact we could probably use someone who owns these 
aspects of vm-dev ;-) If you are willing to write a bit of documentation 
about it, I think that would be quite welcome.

Cheers,
   - Andreas