[etoys-dev] Process for submitting contribution via Monticello?

[Bert Freudenberg]

Am 10.05.2010 um 22:56 schrieb Bert Freudenberg:
> 
> On 10.05.2010, at 22:12, Korakurider wrote:
>> 
>> Hi, All
>> I 've noticed that recently subject of MC notification mail sent to
>> list was changed from 'Etoys: ..' to 'Etoys Inbox: ..'.
> 
> Ah, no, these are both valid. Anyone can submit packages to the Etoys Inbox, but only the packages in Etoys are "official". So you will see both :)
> 
>> I imagine the new process we will follow looks like squeak trunk
>> project though I don't know detail.
> 
> Yes indeed.
> 
>> Could anyone explain it or provide pointer to good description?
>> (Or should I wait for the latest chat log? :-)
> 
> I will. Soon, unless someone beats me to it :)

I started to write it up in detail, but it is hard to know which knowledge to assume. Putting in too much detail makes it look more complex than it really is. So here is just a high-level overview, please ask to clarify the details:

=========================

* Code changes are now committed using Monticello (MC). You simply save a package to the main repository at
	http://source.squeak.org/etoys
  Other developers load these new package using the "update code from server" menu entry.

* Contributors without direct commit access can save their MC packages to 
	http://source.squeak.org/etoysinbox
  A member of the software team then can commit these to the main repository.

* Contributors who dislike Monticello can attach changesets to a tracker ticket:
	http://tracker.squeakland.org/
  Someone else then loads the changeset and saves the changed MC packages, as above.

=========================

This should cover the vast majority of contributions. It is the same as the Squeak Trunk development model, with one difference: we still have an update stream, too:

	http://etoys.squeak.org/updates/updates.list

There you can see it used in the old fashion for code changes. Starting with update 2369 (the first actual 4.1 dev image) it is used in a different way:

My idea was to use the update stream as a release mechanism. It defines fixed points in the ever-changing flow of packages in the repository. Only what is in the update stream will become a "beta release". For this, the update stream can have MC package configuration maps, it loads a specific list of package versions (see updates 2369 and 2372). Also, it contains do-its for image maintainance (e.g. 2373 and 2374).

If I wanted to make a beta release today, I would load updates, but say "no" when asked if the latest packages should be loaded. This would give me an image with update number #2374, and I would know exactly which package versions are in it (namely, the ones loaded by update 2372).

Now, If I *really* wanted to make a beta release today, I would first make a configuration map with all the latest package versions, post it to the update stream, and another change set to install David's new LowSpaceWatcher. Then in a clean dev image I would load updates, save the image, and release it :)

- Bert -