I see a couple of alternatives - 1. Doug uses the script on the swiki to get the changesets and adds the ones I approved to the update stream. I don't know how much more work this is than getting them off the list, might be easier. Doug? 2. KCP/MCP adapt the "send a changeset to the mailing list" code in the image ChangeSorter>>mailToList or something like that to send a bunch of changes to the list, and we can run it once every time we get a bunch of changes approved. Not much work, keeps this part of the process the same as regular harvesting and if done as multiple attachments in one mail it isn't much noise for the list.
What do you guys say?
Daniel
Stephane Ducasse ducasse@iam.unibe.ch wrote:
Hi guys
I'm a bit lost to know how to proceed. Our changesets are based on 3.5 for now and they are available on the page. I do not see the need to send them in the list now. Daniel: noury did a pass and improved it ;)
This afternoon we will have a discussion with the others here
Stef
On Wednesday, May 7, 2003, at 02:19 AM, Daniel Vainsencher wrote:
I say just split the removals. Notify the owners/on squeak-dev, and remove only the packages that can return. We can do the other removals either as people fix the packages or next release. Let's just get it over with, so we can go back to work.
Do that, I'll test vs. KCP, we load KCP, and then resume harvesting the regular stuff.
Daniel
Doug Way dway@riskmetrics.com wrote:
(moving this to the SqF list since we're doing the final coordination now...)
Daniel Vainsencher wrote:
Ok, I've gone through the KCP stuff. I know we orginally decided to do the removals first, but I had an urge, and this doesn't touch so many different classes that I'm very worried about clashes. Anyway, it seems as the designated reviewer for this specific project I got back from my vacation before the removals were done, and I don't see much reason not to merge these now, but I don't mind checking the conflicts if this proposal isn't accepted.
Okay, we need to get moving on the KCP stuff and the removals now, so we can move on with the 3.6 plan (including the various enhancements we've been discussing).
Here's what I would suggest: We incorporate the 10 removals first, all in one batch as Goran and I suggested. This would be very soon, let's say tomorrow. Then, Daniel can check for conflicts between the approved KCP items and the removals. My understanding is that there should be few conflicts.
Then, the adjusted KCP changes can be incorporated (after having at least the preambles posted to the list as a sort of final review). If changes need to be made in a few of the removed packages to account for the KCP changes, perhaps Daniel could inform the package owners of the required changes.
Anyway, I think doing all the removals in one batch is the way to go. There will be two types of problems we'll have to deal with:
- Problems/bugs caused by the removals. These should be relatively
minor and easy to fix, I'd think.
- Problems/bugs/conflicts when re-loading any or all of the 10
packages. These problems will probably be more significant, but these problems need to be pushed back to the package owners at some point anyway. We're moving to a model where package owners need to maintain their packages against base image (prerequisite) changes, so we might as well start this now. It may well be that some packages (such as PWS) are not actively maintained and become obsolete because no one really uses them. If that happens, either a more active package maintainer will have to step up, or the package could be removed from "Squeak Official" status, which would remove it from the public release.
Before thinking about incorporating the 10 removals, I decided to do some testing. To remove the 10 packages, I gave Goran's removal script a try. That appears to work.
Then I decided to try re-adding the 10 packages one by one into an image to get back to the "Full" release. I did it in this order, with the following results:
- SUnit - Yes.
- BaseImage Tests - Yes.
- Celeste Installation - Yes.
- Games (and GamesTests) - Yes.
- VMMaker - No. Not auto-installable, but trying to download it
results in a "MNU: download", even after setting the download directory. 6. MacroBenchmarks - No. Couldn't find a MacroBenchmarks package on SM! 7. PWS Installation - Yes. 8. Scamper - Yes. 9. Speech - No. Installation results in a "MNU: arpabet". 10. Balloon3D - Yes.
So, we need to at least fix the loading problems with the three packages before incorporating the removals.
Beyond that, ideally we'd also like to have Test packages for all 10 of these packages as well, which pass... right now only a few packages have them. I don't think we should hold up incorporating the removals for this, though. But we should probably try to have them available before we move to 3.6beta, at least. Marcus and I can work on bugging the package owners to create these Test packages. All future package removal/additions will have to have a corresponding Test package ahead of time so we don't get in this situation again.
We still need to resolve the issue of how I should load the removal script without SqueakMap, SAR, etc., because those won't be there in the vanilla 3.6alpha image. Probably SAR is the only really important one... I don't know if any require DVS. I guess I'll just have to poke around with the removal scripts and make them into a series of regular file-ins. (An alternative might be to include SAR in the base image for now. SAR should probably be part of the Full and Basic releases anyway. Yes, we would end up splitting off SAR again sometime later as we whittled down to the Minimal image, but so what? Same probably goes for SqueakMap.)
- Doug Way
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
On Wednesday, May 7, 2003, at 08:04 PM, Daniel Vainsencher wrote:
I see a couple of alternatives -
- Doug uses the script on the swiki to get the changesets and adds the
ones I approved to the update stream. I don't know how much more work this is than getting them off the list, might be easier. Doug?
I think that this is the best because we avoid file manipulation. By the way the 0011 is not buggy and plain normal. Daniel noury went over everything and added some fixes but as new changesets.
- KCP/MCP adapt the "send a changeset to the mailing list" code in the
image ChangeSorter>>mailToList or something like that to send a bunch of changes to the list, and we can run it once every time we get a bunch of changes approved. Not much work, keeps this part of the process the same as regular harvesting and if done as multiple attachments in one mail it isn't much noise for the list.
What do you guys say?
Daniel
Stephane Ducasse ducasse@iam.unibe.ch wrote:
Hi guys
I'm a bit lost to know how to proceed. Our changesets are based on 3.5 for now and they are available on the page. I do not see the need to send them in the list now. Daniel: noury did a pass and improved it ;)
This afternoon we will have a discussion with the others here
Stef
On Wednesday, May 7, 2003, at 02:19 AM, Daniel Vainsencher wrote:
I say just split the removals. Notify the owners/on squeak-dev, and remove only the packages that can return. We can do the other removals either as people fix the packages or next release. Let's just get it over with, so we can go back to work.
Do that, I'll test vs. KCP, we load KCP, and then resume harvesting the regular stuff.
Daniel
Doug Way dway@riskmetrics.com wrote:
(moving this to the SqF list since we're doing the final coordination now...)
Daniel Vainsencher wrote:
Ok, I've gone through the KCP stuff. I know we orginally decided to do the removals first, but I had an urge, and this doesn't touch so many different classes that I'm very worried about clashes. Anyway, it seems as the designated reviewer for this specific project I got back from my vacation before the removals were done, and I don't see much reason not to merge these now, but I don't mind checking the conflicts if this proposal isn't accepted.
Okay, we need to get moving on the KCP stuff and the removals now, so we can move on with the 3.6 plan (including the various enhancements we've been discussing).
Here's what I would suggest: We incorporate the 10 removals first, all in one batch as Goran and I suggested. This would be very soon, let's say tomorrow. Then, Daniel can check for conflicts between the approved KCP items and the removals. My understanding is that there should be few conflicts.
Then, the adjusted KCP changes can be incorporated (after having at least the preambles posted to the list as a sort of final review). If changes need to be made in a few of the removed packages to account for the KCP changes, perhaps Daniel could inform the package owners of the required changes.
Anyway, I think doing all the removals in one batch is the way to go. There will be two types of problems we'll have to deal with:
- Problems/bugs caused by the removals. These should be relatively
minor and easy to fix, I'd think.
- Problems/bugs/conflicts when re-loading any or all of the 10
packages. These problems will probably be more significant, but these problems need to be pushed back to the package owners at some point anyway. We're moving to a model where package owners need to maintain their packages against base image (prerequisite) changes, so we might as well start this now. It may well be that some packages (such as PWS) are not actively maintained and become obsolete because no one really uses them. If that happens, either a more active package maintainer will have to step up, or the package could be removed from "Squeak Official" status, which would remove it from the public release.
Before thinking about incorporating the 10 removals, I decided to do some testing. To remove the 10 packages, I gave Goran's removal script a try. That appears to work.
Then I decided to try re-adding the 10 packages one by one into an image to get back to the "Full" release. I did it in this order, with the following results:
- SUnit - Yes.
- BaseImage Tests - Yes.
- Celeste Installation - Yes.
- Games (and GamesTests) - Yes.
- VMMaker - No. Not auto-installable, but trying to download it
results in a "MNU: download", even after setting the download directory. 6. MacroBenchmarks - No. Couldn't find a MacroBenchmarks package on SM! 7. PWS Installation - Yes. 8. Scamper - Yes. 9. Speech - No. Installation results in a "MNU: arpabet". 10. Balloon3D - Yes.
So, we need to at least fix the loading problems with the three packages before incorporating the removals.
Beyond that, ideally we'd also like to have Test packages for all 10 of these packages as well, which pass... right now only a few packages have them. I don't think we should hold up incorporating the removals for this, though. But we should probably try to have them available before we move to 3.6beta, at least. Marcus and I can work on bugging the package owners to create these Test packages. All future package removal/additions will have to have a corresponding Test package ahead of time so we don't get in this situation again.
We still need to resolve the issue of how I should load the removal script without SqueakMap, SAR, etc., because those won't be there in the vanilla 3.6alpha image. Probably SAR is the only really important one... I don't know if any require DVS. I guess I'll just have to poke around with the removal scripts and make them into a series of regular file-ins. (An alternative might be to include SAR in the base image for now. SAR should probably be part of the Full and Basic releases anyway. Yes, we would end up splitting off SAR again sometime later as we whittled down to the Minimal image, but so what? Same probably goes for SqueakMap.)
- Doug Way
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Stephane Ducasse wrote:
On Wednesday, May 7, 2003, at 08:04 PM, Daniel Vainsencher wrote:
I see a couple of alternatives -
- Doug uses the script on the swiki to get the changesets and adds the
ones I approved to the update stream. I don't know how much more work this is than getting them off the list, might be easier. Doug?
I think that this is the best because we avoid file manipulation. By the way the 0011 is not buggy and plain normal. Daniel noury went over everything and added some fixes but as new changesets.
This would be fine. Using the script on the swiki to get the changesets would probably be easiest anyway. So we will do this.
(At first I was thinking that it would still be nice to submit email(s) to the list which simply contained all of the preambles for the changesets, so everyone would see what was about to go in. But this is probably not really necessary, because there are good descriptions on the Swiki page at http://minnow.cc.gatech.edu/squeak/3083, and everyone can see these.)
- Doug
Hi all
After trying to read and understand all the emails in the squeak-dev list I would like to make some points. This is personal and you do not need to reply I try to stay at the fact levels but I will certainly fail.
Squeak is a in transition phase from oligarchy to democracy so this kind of crisis are normal. Still we should leanr from them
Side One: I had the impression that andreas was facing a bit the situation that we were before. I think that he is a bit exaggerating. I think that the situation is improving (slowly sure but improving). Lots of new stuff are happening even if there are not thrown away in the image because one SqC guys like it. Andreas is shouting but he should be the multimedia Guides/Harvester if he wants. This is fun because before when somebody was saying something he got the message: do it this is open source and his stuff has nearly zero chance of getting included if it was not eToys, MM oriented.
Side Two: Andreas has some points: - we need a simple way for people to propose projects as in zope with some simple key points: leader, description, design/solution, history, code
We could have something similar to: http://dev.zope.org/Fishbowl/Introduction.html http://dev.zope.org/Wikis/DevSite/Projects/DeclarativeSecurity/ FrontPage - We should really pay attention that people can get involved.
- Squeak should have a Vision: I like the Smalltalk Platform this includes everything. - We should find way to get faster harvesting.
- We should have a decent web-site: the one of Squeak is bad. Look at the one of Zope for example, the four item on the left is about getting involved. So may be a call for a better web-site is important.
I guess that you all know that but I wanted to share that with you, because we should not kill the Guides before they even can show that they can do it.
Stef
squeakfoundation@lists.squeakfoundation.org
-
Daniel Vainsencher -
Doug Way -
Stephane Ducasse