iSqueak

[stéphane ducasse]

Doug

what we should fix is what do we do with the changes that are in  
3.9alpha stream.
I also have some new changes/fixes on my disc ready to be added to  
the stream.

Stef

>> Actually, instead of having "approval flags" I'd recommend having  
>> "release repositories". E.g., consider that we're setting up a 3.9  
>> repository which defines the "latest" package versions for  
>> everything that ought to be in 3.9.
>>
>> Rather than "approving" a package version in their own repository,  
>> a maintainer (or release master) would publish (or copy) package  
>> versions to the release repository. This has a number of extra  
>> advantages - fixes that turn out to be important for a release can  
>> be put into this repository but may never appear in the "master"  
>> repository for the package (because it might have been a last- 
>> minute workaround). Integration fixes can be done for the release  
>> and then fed back to the package owners.
>>
>> Basically, you're defining your own package environment, treating  
>> the repository as a distribution and decide when you want to  
>> update the distribution from the latest package versions developed  
>> by the owner of the package.
>>
>
> I think this sounds good.  It almost seems like the only way to do  
> it, actually.  (For now, at least.)
>
> The other thing I like about this is that it handles the case in  
> which you're making a big change in a release which needs to cut  
> across several packages.  All the packages are in the same  
> repository, and they can be updated at the same time.  It's more  
> cumbersome if they're spread across different repositories,  
> especially if the person making the change only has access to some  
> of the repositories.
>
> Certainly if you're doing package-detangling work, you'll need to  
> make changes to multiple packages at once.
>
>
>>> The initial maintainership model could err on the side of openness,
>>> maybe even having some people with write access to all packages.   
>>> Then
>>> we could restrict it a bit more later.
>>>
>>
>> With the above model you could restrict commit rights for the  
>> release repository to the people actually working on the release,  
>> whereas access to the "master" repository is limited to whatever  
>> the package owner decides. This seems like a good model to me  
>> because it leaves the responsibilities in the right places.
>>
>
> Ok, so a group of release people would have commit rights to the  
> (3.9) release repository.  I wonder if we might also want the  
> package owners to have commit rights to their packages in the  
> release repository as well.  (Although I guess commit rights are  
> repository-specific, not package-specific?)  Because the release  
> repository may end up being the location of the de facto "latest/ 
> bleeding-edge" version of the package, whereas the "master"  
> repository for the package is more for stable versions.
>
> Well, I guess it's up to the package owner whether they want to do  
> major new development in their own master repository, but then  
> they'd have to worry about merging with the release repository  
> version later.  In some cases that might make sense.  I guess it  
> depends on the package... with something like Kernel, probably all  
> development would happen in the release repository.  With something  
> more external like SqueakMap, most development might happen in the  
> owner's master repository, with the latest version being copied  
> over to the release repository occasionally.
>
> So, a typical scenario would be that a package, say Network, goes  
> through a number of new versions in the release repository during  
> 3.9 development, from Network.3 to Network.17 or something.  (My  
> Monticello ignorance is showing here... I assume that every commit  
> to the package results in a bumped version number?  Looks like I  
> will be getting more familiar with MC soon!)
>
> So anyway, 3.9 final contains Network.17.  The Network package  
> owner may decide to not let any of the interim versions into the  
> master repository for Network, and only add the final Network.17  
> version.  Or he/she may decide that Network.12 is stable enough to  
> be generally useful, and include that one in the master repository  
> as well.  But it might be easiest for the package owner to add new  
> enhancements into the one in the release repository, so there's no  
> merging to worry about later.
>
> As far as SqueakMap goes, I'd imagine that the final/stable  
> versions in the master repositories would typically all be  
> available on SqueakMap for people to use, but we probably wouldn't  
> bother with making all of the interim/alpha release repository  
> versions (e.g. Network.4, Network.5, etc) available on SqueakMap.
>
> Just some thoughts.
>
> Are we ready to go ahead with this? :-)

Yes we should try that.

Stef