On Jun 11, 2005, at 7:16 PM, Andreas Raab wrote:
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? :-)
- Doug
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
On Jun 18, 2005, at 12:44 PM, stéphane ducasse wrote:
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.
Assuming we go ahead with the iSqueak plan, there are two ways to handle this:
1. Start with the iSqueak 3.8 image/packaging as-is. Then re-add those 3.9alpha changes via the new Monticello process. You might be able to just file-in all of the 3.9alpha changesets into the iSqueak 3.8 image, then commit all of the changed MC packages to our new release repository (which doesn't exist yet). Right, Avi? It only gets tricky if there are some order-dependent changes, or do-its, then you might have to post a Config Map/do-it update as Andreas was describing.
Or,
2. Start with our 3.9alpha image, and then re-do the iSqueak packagizing. Might be doable, not sure.
Although I guess you were talking about starting over at 3.8 anyway, right? So I think that means #2 doesn't make any sense, let's just do #1.
- Doug
Andreas mentioned that they coupled cs and packages since squeak itself is not packaged. Just some packages and Tweak. but this is the way to go. So I would go for #1
Stef
On 18 juin 05, at 19:23, Doug Way wrote:
On Jun 18, 2005, at 12:44 PM, stéphane ducasse wrote:
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.
Assuming we go ahead with the iSqueak plan, there are two ways to handle this:
- Start with the iSqueak 3.8 image/packaging as-is. Then re-add
those 3.9alpha changes via the new Monticello process. You might be able to just file-in all of the 3.9alpha changesets into the iSqueak 3.8 image, then commit all of the changed MC packages to our new release repository (which doesn't exist yet). Right, Avi? It only gets tricky if there are some order-dependent changes, or do-its, then you might have to post a Config Map/do-it update as Andreas was describing.
Or,
- Start with our 3.9alpha image, and then re-do the iSqueak
packagizing. Might be doable, not sure.
Although I guess you were talking about starting over at 3.8 anyway, right? So I think that means #2 doesn't make any sense, let's just do #1.
- Doug
That was one reason, the other major reason being that some tricky instance migrations are much easier to accomplish with a do-it. MC only really deals with code, not live objects. We have not tried to leverage the pre/post-load script mechanism, yet.
- Bert -
Am 18.06.2005 um 20:47 schrieb stéphane ducasse:
Andreas mentioned that they coupled cs and packages since squeak itself is not packaged. Just some packages and Tweak. but this is the way to go. So I would go for #1
Stef
On 18 juin 05, at 19:23, Doug Way wrote:
On Jun 18, 2005, at 12:44 PM, stéphane ducasse wrote:
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.
Assuming we go ahead with the iSqueak plan, there are two ways to handle this:
- Start with the iSqueak 3.8 image/packaging as-is. Then re-add
those 3.9alpha changes via the new Monticello process. You might be able to just file-in all of the 3.9alpha changesets into the iSqueak 3.8 image, then commit all of the changed MC packages to our new release repository (which doesn't exist yet). Right, Avi? It only gets tricky if there are some order-dependent changes, or do-its, then you might have to post a Config Map/do-it update as Andreas was describing.
Or,
- Start with our 3.9alpha image, and then re-do the iSqueak
packagizing. Might be doable, not sure.
Although I guess you were talking about starting over at 3.8 anyway, right? So I think that means #2 doesn't make any sense, let's just do #1.
- Doug
On 6/18/05, Doug Way dway@mailcan.com wrote:
- Start with the iSqueak 3.8 image/packaging as-is. Then re-add
those 3.9alpha changes via the new Monticello process. You might be able to just file-in all of the 3.9alpha changesets into the iSqueak 3.8 image, then commit all of the changed MC packages to our new release repository (which doesn't exist yet). Right, Avi?
Yep, right, given your caveat below.
It only gets tricky if there are some order-dependent changes, or do-its, then you might have to post a Config Map/do-it update as Andreas was describing.
- Start with our 3.9alpha image, and then re-do the iSqueak
packagizing. Might be doable, not sure.
Although I guess you were talking about starting over at 3.8 anyway, right? So I think that means #2 doesn't make any sense, let's just do #1.
Agreed, let's do #1.
Avi
On 6/18/05, Doug Way dway@mailcan.com wrote:
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.
We can make commit rights as specific as we want, by hacking on the repository code (I assume we'll start with SqueakSource as a base). But I would probably incline towards either giving someone full access to the release repo or not. If they're working on something pretty core to Squeak, they should probably be allowed to use their judgement about committing versions of packages they don't technically maintain (like a modification to Kernel requiring some change to Collections or something). If they're working on something more external, they should just commit to their own repository and have some release manager copy specific versions into the release repo. I think that's more or less what you say later in your message anyway, just trying to get my own thoughts clear.
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.
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.
I'm not really sure what you mean by "no merging to worry about later". It's perfectly possible, for example, to maintain multiple branches in multiple repositories and be constantly merging between them. Or to have the same versions mirrored across multiple repositories. Or to have some versions in a particular branch in one repository, and some in another, etc. It's probably best in this context to think of repositories more like tags: putting something in the release repository means you're tagging it as "releasable". But it might have been a version that you originally committed to an internal development repository and copied over. Monticello is much more flexible than CVS for that kind of thing because each version carries with it all the ancestry metadata it needs, and a repository is just a collection of individual versions + access rights. Does that clarify things somewhat?
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.
Yeah.
Are we ready to go ahead with this? :-)
Well, let's get a repository set up and see how it goes. What's the current status of the modules.sqf.org server? Does it have the capacity for an instance of SqueakSource for this, or should we find somewhere else to host it for now? Bert, I know you guys have made some mods to SqueakSource as well, would it be easy enough for us to make a fresh copy of your setup and deploy that?
Avi
Well, let's get a repository set up and see how it goes. What's the current status of the modules.sqf.org server? Does it have the capacity for an instance of SqueakSource for this, or should we find somewhere else to host it for now? Bert, I know you guys have made some mods to SqueakSource as well, would it be easy enough for us to make a fresh copy of your setup and deploy that?
We are waiting for a brand new mac os X server (because right now squeaksource is running on our oldest solaris box). As soon as we have it we could really use it for a dedicated ssource. But yes as soon as we have a squeaksource and a stream set up I'm willing to push forward 3.9. Marcus told me that he wants to push some mantis pending items. :)
Stef
On Sun, 19 Jun 2005 19:10:55 +0200, ducasse@iam.unibe.ch said:
Well, let's get a repository set up and see how it goes. What's the current status of the modules.sqf.org server? Does it have the capacity for an instance of SqueakSource for this, or should we find somewhere else to host it for now? Bert, I know you guys have made some mods to SqueakSource as well, would it be easy enough for us to make a fresh copy of your setup and deploy that?
We are waiting for a brand new mac os X server (because right now squeaksource is running on our oldest solaris box). As soon as we have it we could really use it for a dedicated ssource. But yes as soon as we have a squeaksource and a stream set up I'm willing to push forward 3.9. Marcus told me that he wants to push some mantis pending items. :)
So... when will this new server be arriving? :)
Cees also offered to host the repository on the squeakfoundation box. Should we just go with that? (There's already plenty of stuff on the squeaksource.com box, it looks like. :) )
And I guess this would just be the 3.9 "release repository". The individual packages should still have their own master repositories somewhere... not sure where they should go. A few of the Basic packages already have master repositories, let's see, Monticello, probably SqueakMap, that may be about it. Perhaps some of the core ones such as Kernel should go on the same box as the release repository.
- Doug
Hi Doug,
We are waiting for a brand new mac os X server (because right now squeaksource is running on our oldest solaris box). As soon as we have it we could really use it for a dedicated ssource. But yes as soon as we have a squeaksource and a stream set up I'm willing to push forward 3.9. Marcus told me that he wants to push some mantis pending items. :)
So... when will this new server be arriving? :)
I discussed with Stef and since we don't think it makes sense to wait for that server I proposed to host this SqueakSource instance at netstyle.ch.
Cees also offered to host the repository on the squeakfoundation box. Should we just go with that? (There's already plenty of stuff on the squeaksource.com box, it looks like. :) )
If Cees wants to set it up and support it that's of course fine with me as well.
Adrian
And I guess this would just be the 3.9 "release repository". The individual packages should still have their own master repositories somewhere... not sure where they should go. A few of the Basic packages already have master repositories, let's see, Monticello, probably SqueakMap, that may be about it. Perhaps some of the core ones such as Kernel should go on the same box as the release repository.
- Doug
On 6/22/05, Adrian Lienhard adi@netstyle.ch wrote:
I discussed with Stef and since we don't think it makes sense to wait for that server I proposed to host this SqueakSource instance at netstyle.ch.
Cees also offered to host the repository on the squeakfoundation box. Should we just go with that? (There's already plenty of stuff on the squeaksource.com box, it looks like. :) )
If Cees wants to set it up and support it that's of course fine with me as well.
Actually I offered to host it on my own box @hetzner.de, because that machine is not doing a lot at the moment so has gobs of spare capacity. And yes, the offer still stands, I just think someone (or better: two people) should volunteer to help maintaining the stuff (so we can give 24x7 support across time zones, etcetera).
On 6/22/05, Cees De Groot cdegroot@gmail.com wrote:
If Cees wants to set it up and support it that's of course fine with me as well.
Actually I offered to host it on my own box @hetzner.de, because that machine is not doing a lot at the moment so has gobs of spare capacity. And yes, the offer still stands, I just think someone (or better: two people) should volunteer to help maintaining the stuff (so we can give 24x7 support across time zones, etcetera).
Well, either way - I have an image prepared now, so if I can get a small bit of help from you are Adrian to get it running somewhere, that would be great...
Avi
On 6/22/05, Avi Bryant avi.bryant@gmail.com wrote:
Well, either way - I have an image prepared now, so if I can get a small bit of help from you are Adrian to get it running somewhere, that would be great...
Er, make that you *or* Adrian. The assertion that you *are* Adrian is one I won't get into... ;)
Avi
You can log in as isqueak@de-1.tric.nl with your own ssh key. I opened port 9090 in the firewall, you can use that for Seaside. Give me a ring on my GSM (0626270036) if you have any trouble.
Suggestions for a DNS name in the SqF domain are welcome ;-)
On 6/22/05, Avi Bryant avi.bryant@gmail.com wrote:
On 6/22/05, Avi Bryant avi.bryant@gmail.com wrote:
Well, either way - I have an image prepared now, so if I can get a small bit of help from you are Adrian to get it running somewhere, that would be great...
Er, make that you *or* Adrian. The assertion that you *are* Adrian is one I won't get into... ;)
Avi
On 6/22/05, Cees De Groot cdegroot@gmail.com wrote:
You can log in as isqueak@de-1.tric.nl with your own ssh key. I opened port 9090 in the firewall, you can use that for Seaside. Give me a ring on my GSM (0626270036) if you have any trouble.
Ok, so, there's an instance of SqueakSource running at http://de-1.tric.nl:9090/seaside/ss. Next step I guess is to set up the DNS, vhost, ProxyPass etc... also we should put something in place to restart and restore everything if the machine or squeak process goes down, but that can be done by hand for now.
Avi
I have apache+mod_proxy running on that box. If you have a configuration block, I'll put it in. I'll set it up as 'source.squeakfoundation.org'.
On 6/22/05, Avi Bryant avi.bryant@gmail.com wrote:
On 6/22/05, Cees De Groot cdegroot@gmail.com wrote:
You can log in as isqueak@de-1.tric.nl with your own ssh key. I opened port 9090 in the firewall, you can use that for Seaside. Give me a ring on my GSM (0626270036) if you have any trouble.
Ok, so, there's an instance of SqueakSource running at http://de-1.tric.nl:9090/seaside/ss. Next step I guess is to set up the DNS, vhost, ProxyPass etc... also we should put something in place to restart and restore everything if the machine or squeak process goes down, but that can be done by hand for now.
Avi
Sounds great. I was going to say Avi should just go ahead and decide where to put the release repository, but it looks like he's already done that. :)
It'll probably be good to have at least two major community SqueakSource repositories anyway... the one at berne and also this new one (in addition to others such Impara's etc).
On another note, I wonder if it might be useful or possible to have a read-only mirror of this repository, perhaps mirrored nightly. The repository is roughly equivalent in importance to the update stream, which has been mirrored for a long time. Not sure if the SqueakSource squeak image is required to simply read from a repository. Or if the "config map" changeset updates can easily specify a backup repository. Anyway, we don't have to worry about this right now, just something to think about.
- Doug
On Wed, 22 Jun 2005 15:10:09 +0200, "Cees De Groot" cdegroot@gmail.com said:
I have apache+mod_proxy running on that box. If you have a configuration block, I'll put it in. I'll set it up as 'source.squeakfoundation.org'.
On 6/22/05, Avi Bryant avi.bryant@gmail.com wrote:
On 6/22/05, Cees De Groot cdegroot@gmail.com wrote:
You can log in as isqueak@de-1.tric.nl with your own ssh key. I opened port 9090 in the firewall, you can use that for Seaside. Give me a ring on my GSM (0626270036) if you have any trouble.
Ok, so, there's an instance of SqueakSource running at http://de-1.tric.nl:9090/seaside/ss. Next step I guess is to set up the DNS, vhost, ProxyPass etc... also we should put something in place to restart and restore everything if the machine or squeak process goes down, but that can be done by hand for now.
Avi
Hi all
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Now I was thinking about mdc format and I do not really like the idea that you have only delta because this can be as messy as cs. What I like with MC is that on my local folder I have all the code of a package.
I have the impression that if this is a speed problem having a byte- code loader or something like that would be better and we would get all the package self-contained. I asked alex to have a look at its old byte-code loader.
Avi I remember than at ESUG you wanted to have something better (working on VW and ....) but it seems that as our time is counted a working squeak specific solution could be good too. We will see if we can have a working solution instead of a let save the universe one and see what come out.
So we will see what we can produce.
Stef
On Fri, 24 Jun 2005 19:53:02 +0200, "stéphane ducasse" ducasse@iam.unibe.ch said:
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Well, it looks like Cees has http://source.squeakfoundation.org/ up and running. (thanks!)
And it also looks like Avi has added a "Squeak 3.8" project/repository (perhaps as a test).
So, how should we do this... Can we just have one "Squeak 3.9" project/repository, with all of the 30 or so packages (in 3.9) in the same repository? (I notice that most SqueakSource repositories typically only have one package.) Or do we create a separate Project for each package?
Once this is settled and done, I can add the partitioning changeset in the 3.9alpha update stream.
And, master repositories will still need to be set up for most of the base image packages as well. (A few already have them.)
This may mean that it's time to make a final push for volunteers to maintain all of the packages, as well. (the old TNFR project) I think it will actually be somewhat easier to do this, now that people can set up repositories for the packages that they can control directly, rather than having to go through some complicated update-stream process. Goran, are you still interested in spearheading this effort? (I know we already have some packages assigned on that swiki page.)
- Doug
On 6/25/05, Doug Way dway@mailcan.com wrote:
On Fri, 24 Jun 2005 19:53:02 +0200, "stéphane ducasse" ducasse@iam.unibe.ch said:
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Well, it looks like Cees has http://source.squeakfoundation.org/ up and running. (thanks!)
And it also looks like Avi has added a "Squeak 3.8" project/repository (perhaps as a test).
Yeah, just as a test. There are some simple issues I need to work out still with URL mapping before it will actually be functional. I'll do that tomorrow, I guess.
So, how should we do this... Can we just have one "Squeak 3.9" project/repository, with all of the 30 or so packages (in 3.9) in the same repository? (I notice that most SqueakSource repositories typically only have one package.) Or do we create a separate Project for each package?
I'd say we should create a project/repository for each version/branch, with all of the packages in it. That's how MC will work best.
Avi
For me what is important is that - we (the main harvesting guys) can have access to the packages and publish fixes there. - we can push the long pending list of changes that are waiting in 3.9alpha - we stopped even to add to this list but we will have some nice cleaning (removal of dialect stream :), tiles methods...)
So Avi let us know when - you need help (but when the help does not slow you down) - you can explain how we can proceed.
Doug/Avi did you set up a stream for the stuff that cannot be done in MC? Do we use the old stream? Alex fixed (normally) all the loading problems or tagged them so that 3.9alpha can load without problem (but this was before iSqueak).
Stef
On 6/24/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi all
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Ok, this should be basically working now. I've set up projects for Squeak 3.8 and 3.9a; you'll have to register accounts and I can add people as developers etc.
The next thing we need is probably a short tutorial on using MCConfiguration for maintainers. Bert, are you up to it?
Avi
Am 25.06.2005 um 22:05 schrieb Avi Bryant:
On 6/24/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi all
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Ok, this should be basically working now. I've set up projects for Squeak 3.8 and 3.9a; you'll have to register accounts and I can add people as developers etc.
The next thing we need is probably a short tutorial on using MCConfiguration for maintainers. Bert, are you up to it?
Please have a look at
http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/
Then ask back with any questions :)
- Bert -
On 6/26/05, Bert Freudenberg bert@impara.de wrote:
Please have a look at
http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/Then ask back with any questions :)
My first question is about workflow: how often do you save a new config map? Do you only do it when you either add or reorder packages, or need to post an intermediate update to the stream? Or do you save the config map for every stable configuration of versions (whenever all tests are green or whatever)? It seems to be intended more for the former, particularly because the naming seems to be totally manual, whereas with the current dependency system I tend towards the latter.
Do you tend to just have one version of the config map in the repo that you overwrite when things change, or do you end up with a lot with different names (which seems it would really clutter up the repository browser)?
Avi
Am 26.06.2005 um 13:22 schrieb Avi Bryant:
On 6/26/05, Bert Freudenberg bert@impara.de wrote:
Please have a look at
http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/Then ask back with any questions :)
My first question is about workflow: how often do you save a new config map?
Actually, in the Tweak update scheme we do not "save" a config map at all. When we post it to the update stream, it is not retained after loading packages. It is just used as a list of packages that need to be loaded.
Additionally, we have a global config map in the image, which is updated automatically by using the highest-numbered version found in the repository. This config map update is performed after updating from the update stream.
Do you only do it when you either add or reorder packages, or need to post an intermediate update to the stream?
Yes, that's the current practice, because Tweak is still undergoing heavy development.
Or do you save the config map for every stable configuration of versions (whenever all tests are green or whatever)? It seems to be intended more for the former, particularly because the naming seems to be totally manual, whereas with the current dependency system I tend towards the latter.
True. We rely on the update-stream / config map hybrid, so previous config maps are only found in the update stream, not as explicitly versioned files.
Do you tend to just have one version of the config map in the repo that you overwrite when things change, or do you end up with a lot with different names (which seems it would really clutter up the repository browser)?
As I said, we do not create config map files at all right now, so this part of the code is a bit underdeveloped. Our squeaksource version supports uploading of config maps, but we do not use this right now. When I experimented with this, I uploaded the updated config map under the same name. Locally, I even explicitely forbid caching of config map files because the name was not guaranteed to be unique.
OTOH, config maps are a lot like MCVersions, so they would benefit from the same naming scheme when they are stored in files. We might want to implement something along these lines, or actually go and merge versions and config maps into one (I imagine MCConfiguration and MCVersion could share a common superclass handling dependencies and naming, MCVersion would additionally have code, MCConfiguration would have repository info ...).
- Bert -
For what it's worth, I think the process Bert describes below sounds OK for 3.9alpha for now... the "update stream/config map hybrid". Do you agree Avi? We could tweak this as we go along.
Also, keep in mind that once in a while, if we have a stable set of alpha packages, those could also be published to SqueakMap for the world at large to play around with. (Maybe on those occasions we would also save an MC config map, I don't know.)
- Doug
On Sun, 26 Jun 2005 15:47:53 +0200, "Bert Freudenberg" bert@impara.de said:
Am 26.06.2005 um 13:22 schrieb Avi Bryant:
On 6/26/05, Bert Freudenberg bert@impara.de wrote:
Please have a look at
http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/Then ask back with any questions :)
My first question is about workflow: how often do you save a new config map?
Actually, in the Tweak update scheme we do not "save" a config map at all. When we post it to the update stream, it is not retained after loading packages. It is just used as a list of packages that need to be loaded.
Additionally, we have a global config map in the image, which is updated automatically by using the highest-numbered version found in the repository. This config map update is performed after updating from the update stream.
Do you only do it when you either add or reorder packages, or need to post an intermediate update to the stream?
Yes, that's the current practice, because Tweak is still undergoing heavy development.
Or do you save the config map for every stable configuration of versions (whenever all tests are green or whatever)? It seems to be intended more for the former, particularly because the naming seems to be totally manual, whereas with the current dependency system I tend towards the latter.
True. We rely on the update-stream / config map hybrid, so previous config maps are only found in the update stream, not as explicitly versioned files.
Do you tend to just have one version of the config map in the repo that you overwrite when things change, or do you end up with a lot with different names (which seems it would really clutter up the repository browser)?
As I said, we do not create config map files at all right now, so this part of the code is a bit underdeveloped. Our squeaksource version supports uploading of config maps, but we do not use this right now. When I experimented with this, I uploaded the updated config map under the same name. Locally, I even explicitely forbid caching of config map files because the name was not guaranteed to be unique.
OTOH, config maps are a lot like MCVersions, so they would benefit from the same naming scheme when they are stored in files. We might want to implement something along these lines, or actually go and merge versions and config maps into one (I imagine MCConfiguration and MCVersion could share a common superclass handling dependencies and naming, MCVersion would additionally have code, MCConfiguration would have repository info ...).
- Bert -
On 6/27/05, Doug Way dway@mailcan.com wrote:
For what it's worth, I think the process Bert describes below sounds OK for 3.9alpha for now... the "update stream/config map hybrid". Do you agree Avi? We could tweak this as we go along.
Yep, I agree.
Avi
On Jun 25, 2005, at 4:05 PM, Avi Bryant wrote:
On 6/24/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi all
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Ok, this should be basically working now. I've set up projects for Squeak 3.8 and 3.9a; you'll have to register accounts and I can add people as developers etc.
Ok, I set up my member account at source.squeakfoundation.org.
(That was yesterday. Hmm, http://source.squeakfoundation.org seems to be down at the moment right now, though.)
I assume we still need to add the packages to the 39a repository next. And also set several people to have commit (developer?) access to the 39a repository, once they've registered accounts. (We don't really need a huge number of people with this level of access, since most package development can happen outside of this repository. But it should be at least 5-6 people, the people who have recently done update stream work.)
- Doug
I created mine.
Perhaps this mailing list should be setup in such a way that the ML address is used instead of the author when replying.
Cheers, Alexandre
On Mon, Jun 27, 2005 at 12:17:36AM -0400, Doug Way wrote:
On Jun 25, 2005, at 4:05 PM, Avi Bryant wrote:
On 6/24/05, stéphane ducasse ducasse@iam.unibe.ch wrote:
Hi all
Let us (me alex) know when 3.9 squeaksource is ready because we would like to help.
Ok, this should be basically working now. I've set up projects for Squeak 3.8 and 3.9a; you'll have to register accounts and I can add people as developers etc.
Ok, I set up my member account at source.squeakfoundation.org.
(That was yesterday. Hmm, http://source.squeakfoundation.org seems to be down at the moment right now, though.)
I assume we still need to add the packages to the 39a repository next. And also set several people to have commit (developer?) access to the 39a repository, once they've registered accounts. (We don't really need a huge number of people with this level of access, since most package development can happen outside of this repository. But it should be at least 5-6 people, the people who have recently done update stream work.)
- Doug
On 6/27/05, Doug Way dway@mailcan.com wrote:
Ok, I set up my member account at source.squeakfoundation.org.
(That was yesterday. Hmm, http://source.squeakfoundation.org seems to be down at the moment right now, though.)
Hm, odd, it's back up now and I didn't do anything to restart it...
I assume we still need to add the packages to the 39a repository next. And also set several people to have commit (developer?) access to the 39a repository, once they've registered accounts. (We don't really need a huge number of people with this level of access, since most package development can happen outside of this repository. But it should be at least 5-6 people, the people who have recently done update stream work.)
I've added you and Alex.
Avi
Ok. What the next move then ? What do we store in the new squeaksource? What do you think about the following piece of code?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |squeak packages|
packagesName := Set new. SystemOrganization categories do: [:name| packagesName add: (name subStrings: {$-}) first].
packages := OrderedCollection new. packagesName do: [:name| |p| PackageInfo registerPackageName: name. p := MCPackage new name: name. packages add: p. MCWorkingCopy forPackage: p].
PackageInfo registerPackageName: 'SqueakImage'. squeak := MCWorkingCopy forPackage: (MCPackage new name: 'SqueakImage').
packages do: [:p| squeak requirePackage: p]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Do you store the SqueakImage package ?
Cheers, Alexandre
On Mon, Jun 27, 2005 at 01:26:53PM +0200, Avi Bryant wrote:
On 6/27/05, Doug Way dway@mailcan.com wrote:
Ok, I set up my member account at source.squeakfoundation.org.
(That was yesterday. Hmm, http://source.squeakfoundation.org seems to be down at the moment right now, though.)
Hm, odd, it's back up now and I didn't do anything to restart it...
I assume we still need to add the packages to the 39a repository next. And also set several people to have commit (developer?) access to the 39a repository, once they've registered accounts. (We don't really need a huge number of people with this level of access, since most package development can happen outside of this repository. But it should be at least 5-6 people, the people who have recently done update stream work.)
I've added you and Alex.
Avi
On 6/27/05, Alexandre Bergel bergel@iam.unibe.ch wrote:
Ok. What the next move then ? What do we store in the new squeaksource? What do you think about the following piece of code?
Alex,
Please see the earlier messages about the iSqueak packaging that's already been done...
Avi
But the Project 39a is still empty...
I have many changes related to the system change notification that are waiting...
Alexandre
On Mon, Jun 27, 2005 at 04:44:01PM +0200, Avi Bryant wrote:
On 6/27/05, Alexandre Bergel bergel@iam.unibe.ch wrote:
Ok. What the next move then ? What do we store in the new squeaksource? What do you think about the following piece of code?
Alex,
Please see the earlier messages about the iSqueak packaging that's already been done...
Avi
Am 19.06.2005 um 16:43 schrieb Avi Bryant:
Bert, I know you guys have made some mods to SqueakSource as well, would it be easy enough for us to make a fresh copy of your setup and deploy that?
I guess so. Our version is a bit less open than the regular SqueakSource, for example, only super users can create projects, and non-public projects are not visible at all. This may or may not be what you want for the official release server. That stuff is hard- coded, but should be easy to find if you need to revert, thanks to the excellent design of the SqueakSource code base in general.
There should be only a few impara-specific things in there, like hard- coded email addresses (they used to point to Berne).
The most valuable addition you'll find in there might be the support for automated generation and caching of differential packages (.mcd). This immensely speeds up upgrading of packages (in particular large packages) via configuration maps - it almost achieves the speed of changesets.
My code is at
http://source.impara.de/ss.html
Feel free to use.
- Bert -
On Jun 19, 2005, at 10:43 AM, Avi Bryant wrote:
... I'm not really sure what you mean by "no merging to worry about later". It's perfectly possible, for example, to maintain multiple branches in multiple repositories and be constantly merging between them. Or to have the same versions mirrored across multiple repositories. Or to have some versions in a particular branch in one repository, and some in another, etc. It's probably best in this context to think of repositories more like tags: putting something in the release repository means you're tagging it as "releasable". But it might have been a version that you originally committed to an internal development repository and copied over. Monticello is much more flexible than CVS for that kind of thing because each version carries with it all the ancestry metadata it needs, and a repository is just a collection of individual versions + access rights. Does that clarify things somewhat?
Yes, I forgot that a version (no matter in what repository) carries its ancestry metadata, which is a nice feature.
- Doug
packages@lists.squeakfoundation.org
-
Adrian Lienhard -
Alexandre Bergel -
Avi Bryant -
Bert Freudenberg -
Cees De Groot -
Doug Way -
stéphane ducasse