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

[Stephan R. <sr...@ev...>]

Goran,

thank you for reading my proposal.

A few explanations to your questions and comments to my proposal are following:

gor...@bl... wrote:

<snipped>

>>On Sat, 17 Aug 2002, Stephan Rudlof wrote:

<snipped>

>>>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.

This is, what I've meant. More exactly: Unstable code which *could* affect
the quality of the main branch must *not* reside in the main branch.

> 
> 
>>>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.

I mean the sources generated by VMMaker here: an 'official' port doesn't
necessarily contain all possible plugins. And it runs stable with a VM
generated from whatever Squeak version.

AFAIK VMMaker generated sources are not at SF.

> 
> 
>>>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.

Do you mean 'by all port maintainers' here?

> 
> 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

I have to read this.

> 
> 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.

Sounds good.

> 
> 
>>>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

Thanks!

> 
> 
>>>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?

Yes.

> I
> still think the port maintainers should have cooperative commit ability
> on the "Cross" subtree. Right?

Yes, but this means they have to cooperate.
My intent here was to lower the burden for them by giving some of the
necessary management tasks to the plugin maintainers. Possibly this is too
complicated.

> 
> 
>>>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.

Why not.

> 
> 
>>>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...

Don't know: there may be a Slang plugin writer, not knowing too much about
platform specific issues, and working with another person.

The other aspect (which I've had in mind at 3. above) is the management
issue: the filtering of new plugins before giving them a chance to come to
SqueakSF. A plugin writer needs a person with commit access to put it there
(independently from putting it in main branch (trunk) or a branch).

> 
> 
>>>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".

Agreed with one exception:
My idea with 4., 5. and especially 6. has been,
- to allow plugin maintainers to change parts of the trunk,
  which are *guaranteed* not to affect an 'official' port residing in the
  VMMaker generated src_OSname dirs,
- to let the plugin maintainers do some of the necessary management tasks.

Again this may be too complicated.

> 
> 
>>>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.

Agreed.

> 
> 
>>>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)).

<snipped>


Greetings,

Stephan
--
Stephan Rudlof (sr...@ev...)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3