[Squeak-VMdev] Re: [SqueakSF] SqeakSF Policy Proposal [was: Re: [VM 3.2-4] build problems, if an acinclude.m4 has been added]

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

This is a response to Ian and Stephan. I am cc-ing this to the Squeak-vm
list too.

In summary:

- Stephan has emailed Ian and they have exchanged a few emails about SF
etc.
- Stephan was probably not aware of the last discussion about SF and the
agreement between the port maintainers how CVS should be handled (and my
promise to deliver a howto/policy which I began 2 months ago before
summer kicked in)
- Ian cc:d me and this is my detailed response

The important pieces that came up below that we haven't discussed
earlier (I think) is how plugins should be handled. I don't have much to
say in that area - read below and please share your thoughts. Tim? Ian?
Andras? John? :-)

I am revisiting the Swiki pages I wrote that begin at:
http://minnow.cc.gatech.edu/squeak/2512

If you haven't read them - PLEASE DO SO and respond on this list.

When we finally all agree on that they "are enough" then we can perhaps
shout a bit on Squeak-dev and email all the people registered on SF to
see if we can simply just go with this model.

regards, Göran

Ian Piumarta <ian...@in...> wrote:
> Hi Stephan,
> 
> Thanks for your policy proposal.  The spirit is very close to what we had
> agreed upon a few months ago.  Goran is the appointed "impartial policy
> arbiter, SF constitution lawyer and CVS expert", so I'm forwarding your
> message to him.  I'm not sure how far along he is in the process of
> codifying the SF policy we agreed on (being busy with SqueakMap and no
> doubt countless other wonderful things) but he's been trusted with working
> out what's best for everyone concerned with keeping VM sources at
> SF.  He's definitely the person who can make the best use of your
> suggestions.
> 
> But I can't resist making just a few "devil's advocate" type comments...;)
> 
> > What is the expected win-win situation?
> > ---------------------------------------
> > 
> > Port maintainers have
> > - full control over the 'official' part,
> 
> We already do (regardless of SF ;^p).
> 
> > - less work than before (if plugins are partly managed by others),
> 
> I'm not so sure.  Look, for example, at the RegExpPlugin.  Andrew can
> build and test it on one platform, but on other platforms (and even to a
> large extent on his "local" platform) there are lots of portability and
> version issues.  In the end it's still the maintainers who have to figure
> out all the fine details (which are what take most of the time).
> 
> But I admit that having a single source tree at SF would make _Andrew_'s
> life easier by giving him an up-to-date framework into which he could drop
> his plugin for testing before moving on to the fine-tuning stage.
> 
> > - a backup'ed source repository.
> 
> We already do.  (I have lost count of how many "rsync"s get fired off on
> my machine from time to time.  And the place my sources get "rsync"ed to
> is itself backed up [along with the whole of INRIA] to optical disk every
> night: if I wanted to grab a copy of Squeak from 5 years ago, without any
> intervening back-patches that might have been retrofitted, it's sitting
> right there... ;)
> 
> Regards,
> 
> Ian

I don't think anyone disagrees with these positive effects of using SF.
In fact - my impression is that we actually all already have agreed on
using SF as long as we follow the model that we painstakingly :-)
coevolved over email (and that I have begun to describe over at
http://minnow.cc.gatech.edu/squeak/2512)

> On Sat, 17 Aug 2002, Stephan Rudlof wrote:
> 
> > Hi Ian,
> > 
> > thank you for your exhaustive answer!
> > 
> > I try to make my answer dense (to not stealing to much from you spare time).
> > 
> > 1. I understand your point of view.
> > 2. I appreciate quality control.
> > 3. I do *not* want to make the maintainers more work.
> > 4. I want to have a win-win situation for both port maintainers and others.
> > 5. I'm willing to contribute, but...
> > 6. I do *not* want to change any 'official' code without having the OK from
> > the maintainer(s).
> > 7. I don't need commit access to SqueakSF in the *current* situation.
> > 
> > 
> > In the following there is a proposal, which hopefully brings these issues
> > forward. You may publish it, if you like.
> > 
> > 
> > SqueakSF Policy Proposal
> > ------------------------
> > 
> > Preamble: SqueakSF is a repository for stable developer code.
> > Stable means the port maintainers have to decide, if they trust something
> > new here. Developer code means, that merely users of Squeak shouldn't deal
> > with the source tree at SqueakSF at all (but they may download some
> > distribution from there). Unstable code which *could* affect the quality of
> > the main branch must *not* reside in it.

Note: the model we agreed upon actually allows such code but NOT on the
trunk.

> > 0. To get this policy work, there is the need to introduce platform specific
> > src trees - e.g. src_unix, src_win, src_mac - for the different ports, which
> > contain the 'official' proven sources. Currently there aren't any, but it
> > isn't possible to store full ports at SF without them. There has to be one
> > source tree for each port, since on each platform there may be a different
> > number of plugins or (not so good) a different version of the VM, which are
> > working in reality.

If I am not mistaken the source tree is partitioned today into one tree
for each port and one "Cross" tree with everything in common... Perhaps
I misunderstood.

> > 1. Only the port maintainers and - to be determined - plugin maintainer(s)
> > have commit access to SqueakSF.

The model (I will not repeat "The model we agreed upon..." from here on
but you can perhaps fill that in yourself) says that the port
maintainers (http://minnow.cc.gatech.edu/squeak/2513) are the only ones
with commit access to the TRUNK. But others can commit to branches.

We may try to enforce this techincally but personally I think it would
also suffice with this as a "rule" for us to follow - after all, getting
commit access is still a filter to keep "idiots" out. :-)

> > 2. Only the port maintainers have commit access to their platform specific
> > parts of the source tree (this includes src_OSname); with one exception
> > described in 5.. Others, which want to contribute changes here, have to ask
> > the corresponding port maintainer, how to deal with this situation: this
> > could lead to a branch, to just sending patches, etc..

Well, typically this is almost the same as we agreed - but the TRUNK of
"Cross" is typically "co-maintained" by the maintainer.

Contributers can get branches to play on and either produce patch-files
or merge-instructions as long as they follow the branching and tag rules
described on: http://minnow.cc.gatech.edu/squeak/2517

Since we never merge from trunk to branches and everybody follows those
rules then it should be quite simple for a port maintainer to pick up
contributions from branches as long as the contributer explains the
branch tag and between what tags the actual contibution can be produced
from.

> > 3. It has to be known, which plugin maintainer/s is/are responsible for
> > which plugin and has/have corresponding commit access.

Ah. Plugins have not been discussed so far. I will pick up your views
and throw them up at the "table" (the mess at the bottom of the page
which is my clipboard for collecting the thoughts) at:
http://minnow.cc.gatech.edu/squeak/2512

> > 4. Only the plugin maintainer/s has/have commit access to the Cross subtree.

Hmmm. I don't think I am following you here. When you say "plugin
maintainer" you mean another role than the port maintainer, right? I
still think the port maintainers should have cooperative commit ability
on the "Cross" subtree. Right?

> > 5. If there is a *new* plugin needing platform specific sources, the plugin
> > maintainer is allowed to *only* commit platform specific plugin sources in
> > the corresponding plugin dirs. He/she is *not* allowed to commit into the
> > src_OSname tree. 'New plugin' means, that this only applies, if the plugin
> > dirs have to be newly created.
> > 
> > 6. A plugin maintainer is *not* allowed to *change* any plugin sources
> > (independently wherever they are), if it is already in one or more of the
> > 'official' src_OSname trees; since this could endanger the quality of the
> > port. He has to make a *branch* and to inform each port maintainer
> > personally, who has the plugin in its 'official' src_OSname tree and to wait
> > for a feedback (of course he could made the changes public elsewhere). If
> > he/she has a positive feedback of an only platform affected port maintainer,
> > he/she is allowed to commit the changes for this port into the main branch.
> > If there is a change in the Cross part *all* port maintainers have to give
> > their OK, of course!

Ok, I will await input from the port maintainers on these issues - they
have a much better understanding of the VM to decide on these rules.

> > 7. There may be special snapshots as downloadable archives for 'official'
> > *distributions*, too.

Yes.

> > 
> > Notes
> > -----
> > 
> > To 0.: It also may be src/unix, src/win, src/mac, etc., but hopefully the
> > idea is clear.
> > 
> > To 2.: The port maintainers should publish their port specific SqueakSF
> > policy at SqueakSF.

Well. Or on the Swiki perhaps - that is where I have placed the "rules"
now.

> > To 3.: A plugin maintainer is *not* responsible for the Slang part, but
> > obviously should have some communication with the plugin writer, if
> > necessary: this means the potential need of synchronizing changed Slang with
> > changed SF code. A refinement of this policy may be necessary here.

Hmm, sounds a bit convoluted (right word?). I think we should keep "one
person per plugin" as a general rule somehow...

> > To 4.: This would be sufficient for plugins without platform specific code.
> > 
> > To 4. and 5.: For you the procedure would look like the following: you see -
> > via update, commit mails or personal eMail - 'Oh, there is a new plugin!'.
> > Before you notice its existence, it doesn't bother you, since per default
> > (without starting VMMaker and generating a new internal/external plugin
> > partitioning) just the proven (by you) plugins are compiled. And just you
> > have commit access to src_unix, platforms/unix/config, etc.. Some time you
> > think it's time to give the plugin a chance: you check the compatibility of
> > the plugin with your 'official' port by compiling it and whatever other
> > checks and change your src_OSname and config tree accordingly. Then it is
> > accepted (it would be nice to state this in some commit message).

I would agree that this in principal sounds how it should work. The
difference being that it is the TRUNK that the port maintainers "own".

> > To 6. This also effects Cross-only plugins, since they also could break an
> > 'official' port. Practically this point is a big barrier for changing a
> > plugin, if it is once accepted by one of the port maintainers. This should
> > be some pressure towards quality of plugins before thinking of putting them
> > to SF. But it's easy to introduce *new* plugins!

Sounds like a true observation.

> > To 7. SqueakSF could be a good central place for distributions. The
> > distribution snapshots may be tagged. Ideally the image used to generate

They SHOULD be tagged.

> > some distribution should be stored with it, too: this would ease changing
> > the VM (e.g. I have had problems using VMMaker with your source tree, since
> > my image is not compatible with the generated plugins (some are just missing)).
> > 
> > 
> > Do you think this is rigid enough?

Well, personally I simply volunteered to write the pages on minnow
because I know CVS and wanted to help out getting a concensus. I don't
know much about the VM or how the plugins relate to it.

I will 

> > 
> > What I could do:
> > I'm a volunteer for checking/filtering and commiting new plugins, but
> > limited to the Cross platform and Linux(my OS)/Unix platform part. My time
> > may be limited to a few hours a week, though.
> > I'm not hungry to do this work, so I'd also be happy, if another person
> > wants to make this and will be chosen.
> > 
> > 
> > What is the expected win-win situation?
> > ---------------------------------------
> > 
> > Port maintainers have
> > - full control over the 'official' part,
> > - less work than before (if plugins are partly managed by others),
> > - a backup'ed source repository.
> > 
> > Users of SqueakSF without any commit access
> > - always know exactly, which is the 'official' (development) port,
> > - only have to deal with one source tree,
> > - it's easy to stay uptodate for them (it's just an CVS checkout/update
> > without looking onto a web side, downloading, etc.).
> > 
> > All have
> > - a known process, how to get new things into SqueakSF,
> > - a quality ensuring process,
> > - a central repository with all Squeak relevant source code,
> > - to work with only *one* source tree,
> > - know where to look for the actual developer version.
> > 
> > 
> > Greetings,
> > 
> > Stephan
> > 
> > 
> > Ian Piumarta wrote:
> > > Hi Stephan,
> > >
> > >
> > >>Is the tarball of 3.2-5devel 'frozen' (for the case that there should be
> > >>some other problem)?
> > >
> > >
> > > I think it entirely unlikely there'll be any more problems with this
> > > version before it's promoted to "stable".
> > >
> > >
> > >>Bugs are not the problem. But it's annoying if there is a better version,
> > >>but you do not know thereof. And think the better one is the more unstable
> > >>one...
> > >
> > >
> > > Although "devel" is intended to mean "this might contain experimental
> > > code", in _practice_ it really means "accumulating bug fixes until
> > > they reach critical mass at which time I will transform myself into
> > > the latest stable version".  Nothing experimental has been in the VM
> > > for a while now, so the "devel" version is usually the most "correct"
> > > one (and definitely the one that anybody building from source should
> > > be using, since it's the only version that I [and several other
> > > people] are using on a daily basis to build VMs).
> > >
> > >
> > >>I have another question.  I've encountered not to be able to generate
> > >>all plugins by VMMaker as you have done it, if I use the platform
> > >>sources from SF (for 3.2-4, but should'nt be better for later
> > >>releases).
> > >
> > >
> > > The SF sources are not compatible with my sources.  I do not (and have
> > > never) had any intention of maintaining them in their present form.
> > > If they're broken then it's not my fault -- I disown them entirely.
> > > (And they are, as far as I know, *dead*.  There have been no commits
> > > to the Unix part of the repository for several months, and some pretty
> > > serious problems have been fixed in the VM during that time.)  They
> > > were created without my knowledge (or support) from a _stale_ copy of
> > > a pre-release version of 3.1.
> > >
> > >
> > >>If I use your platform sources it should work
> > >
> > >
> > > I hope so!  My sources are 100% VMM-compatible and are intended to
> > > remain that way.  I generate all of my plugin and VM sources using
> > > VMM.  If you notice any problems with using my sources with VMM then
> > > _please_ let me know so that we can fix it as soon as possible!
> > >
> > >
> > >>Do you plan to synchronize your sources with SF?
> > >
> > >
> > > At some point I will probably erase everything under "platforms/unix"
> > > on SF and replace it with my sources.  But it's not a priority for me.
> > >
> > >
> > >>Do you plan to stay synchronized with SF?
> > >
> > >
> > > The major interest of SF is in bug tracking and supporting "forks"
> > > away from the main branch in which significant experimental code
> > > (beyond what could be managed by keeping a few diffs around) can be
> > > maintained until they're either abandoned or ready for merging into
> > > the "official" sources, rather than for allowing any kind of public
> > > write access to the main branch.  If I put my sources on SF then it
> > > would be on the understanding that commits to the main branch were
> > > performed by me or by someone else who has been given the "okay" to
> > > commit something on my behalf.  I'd be very unhappy to see random
> > > people commiting arbitrary changes to the sources (as happened with
> > > the SF unix "forks" in the past) and I'd probably "manage" such a
> > > situation by periodically erasing the entire SF unix content and
> > > replacing it with a fresh copy of my sources.  "Open source" in no way
> > > implies "publicly writable" -- and must _never_ imply such if the
> > > source has any hope of remaining release-quality.  (You can count the
> > > number of people who have trunk write access to BSD repository on one
> > > hand.  You can count the number of people who have write access to the
> > > Linux kernel repository on one finger. ;-)
> > >
> > > There was a long discussion about this a few months ago and the above
> > > is more or less the concensus that was reached on how sources stored
> > > on SF would be treated.  (FWIW, my position on this is pretty close to
> > > Andreas' position w.r.t. the Windows sources.  He is just as
> > > distrustful of "cruft" as I am.)
> > >
> > > OTOH, even if/when I upload my sources on SF, the "master copy" would
> > > always live on my disk.  The trunk on SF would really just be a
> > > "cache" onto those sources (but with the possibility of developers
> > > forking their own experimental branches, and just maybe the
> > > possibility that merging experimental code back into the trunk might
> > > be slightly easier for me than the current practice of people sending
> > > me context diffs of changes they want applied).

Sounds fair I think. It is VERY important that the port maintainers
still are in full control for this to work. I mean, if not why even
bother? An SF repository has no chance if not the port maintainers are
"in the game". And that is what the policy is all about. And since we
actually came to an agreement a while ago, it's all green light as long
as we follow the rules. IMHO.

> > >>This would ease some things and the developer version of your port
> > >>would be available at a developer place ;-)
> > >
> > >
> > > Hmm.  I remain to be convinced that CVS access has any desirable
> > > properties that a combination of tarball + browsable source tree
> > > (which is what I have on my Squeak site right now) does not have.
> > > (The "devel" sources are even recompiled, and fresh binary and source
> > > distributions created automatically, every night.)

I would probably mention possibility of generating ChangeLogs and
traceability as well as branch management as the big "wins".

> > > Copies of the Unix source have been uploaded twice (2.8 then 3.1) to
> > > SF (both using stale source archives).  The first time the result was
> > > a complete disaster (the code got worse and _way_ more buggy over time
> > > as 15 or so people hammered on it without sufficient "overall
> > > perspective").  The second time was a little better (mainly because
> > > Lex and Ned know the code quite well) but it still eventually drifted
> > > away from what I would consider release-quality code.  Hence the
> > > absolute need for some kind of quality control policy (which we've
> > > already kind of agreed on, however "draconian" it might seem) where

I would call it "practical". There is no "ccvs user experience"
difference whatsoever for Joe Shmoe if he can commit to an experimental
branch-playground instead of to the trunk.

> > > precisely one maintainer is responsible for committing changes to the
> > > trunk in a given subtree in the repository.  (Currently this means
> > > John Mc [mac], Andreas [win] and myself [unix] for the platforms, Tim
> > > for all the VMM-related stuff [outside the platdep trees], and
> > > individual authors for their own plugins in the Cross/plugins subtree
> > > [unless they want to delegate responsibility to one of the other
> > > maintainers]).

Yes, I assume this was essentially what Stephan described above - I am
not sure.
Again - someone else need to analyse how the plugins should be handled.

> > >
> > >
> > >>So SF is very limited: e.g. putting ACG's RePlugin there, but having
> > >>outdated unix platform / conf sources?
> > >
> > >
> > > Ahh, thanks for reminding me!  I have to pull that into my sources.
> > > (So maybe there will be _one_ more change to the Unix sources before
> > > 3.2-5 becomes "stable". ;)
> > >
> > >
> > >>Note: private communication, but you may post an answer and/or this
> > >>to the list.
> > >
> > >
> > > Well, I've absolutely _no_ desire whatsoever to restart a huge,
> > > pointless public debate about SF given that we (the subscribers to the
> > > SF developers list) have pretty much come to an agreement about how it
> > > should be managed.  So I think I prefer to keep this private.
> > >
> > > One of these days I'll get round to uploading a reliable copy of the
> > > Unix sources to SF (and maybe one of these days Goran will finish the
> > > "SF Squeak Constitution" explaining [more diplomatically than I ever
> > > could] to would-be developers why they aren't allowed to commit to the
> > > trunk -- which is pretty much the only thing holding me back from
> > > uploading at the moment...).

Ok, hint taken. :-) I am looking over the Swiki pages as we speak.

regards, Göran