Hi all!
(cross posting since Ken's recent post touches on the very same aspects)
I have been re-reading the archive (=the packages team archive) to see where we are and what I had promised to do. :) I am a bit unsire about the latest development. I had my sights set on this (brief description): - Get Universes and SM playing together. As promised by me to Lex and the team. - Use PIs to partition the image. The good ol TFNR idea, which Ken now also expresses in his post. - Tie the PIs to corresponding SM entries. This is key to get the full connection to maintainers and their emails etc. - Gradually move to maintaining these "image packages" as MCs "released on SM", instead of using changesets in the stream. This part obviously is different from the recent plans in the Package team. - Add my planned dependency model in parallell with Universes. They in fact complement each other quite nicely when thinking more closely about it.
Now it seems like the plan is to move to using something independent of SM, which means I have no idea on how to proceed with the above. Perhaps I am not interpreting the plan correct - then you all may of course explain it to me and slap me. :)
I have also some serious doubts about schemes/models that depend on "community work". With that I mean work "by" the community "for" the community, eh, if you know what I mean - instead of work "by" yourself "for" yourself. Hmmm, Ken has a much better english than me, but he is essentially saying the same thing.
Harvesting is a typical example, an unselfish act for the good of all - not directly connected to any personal immediate need. Or trying to maintain a Universe, yes, I *do* have doubts about that model - but at the same time I want to enable it - because I may very well be wrong :).
Or staking out the image, an act which has stalled numerous times for that specific reason I think. All these activities have that in common - they are "non individual" activities relying on community members to do the work "for the benefit of all".
I have come to the personal conclusion that schemes depending on such work have a high risk of failure in the Squeak community. We simply aren't that good at it. We are much more individualistic and we like to scratch our own itches, which means there are two things we are really good at:
- Maintaining our *own* packages, typically driven by our own needs in combination with pride and "feeling good" when other people appreciate your work.
- Finding and fixing bugs in other Squeakers' packages but almost always driven by our *own* projects/packages, we simply fix stuff we stumble over.
So my view is that we need a system which relies on such individual work only, or at least to 95%.
Ken asked "What are we waiting for?" and... I am not sure. The PI-partitioning bit - which is key here - should simply "be done" IMHO. I say let's get *a single person* to just do it and push a .cs into the stream which creates the PIs. I was inclined to get Doug to do it (being v3.9 boss and all), but I don't really care as long as someone does it. Again, I am not sure how this plays with the latest plans/developments (read the packages archive for details).
Ok, over and out.
regards, Göran
Hi Göran,
Let me respond to the end of your message first:
Ken asked "What are we waiting for?" and... I am not sure. The PI-partitioning bit - which is key here - should simply "be done" IMHO. I say let's get *a single person* to just do it and push a .cs into the stream which creates the PIs. I was inclined to get Doug to do it (being v3.9 boss and all), but I don't really care as long as someone does it.
The decision that I think we're all pretty comfortable with at this point (at least, I haven't heard anything to the contrary) was to use the iSqueak image as the basis for 3.9 going forward. This already has an initial partitioning done. So, I think the plan is or would be to reset the 3.9 stream and then dump in the changeset that creates the iSqueak image. Doug, is that what you're doing? At any rate, I agree: let's Just Do It.
I had my sights set on this (brief description): - Get Universes and SM playing together. As promised by me to Lex and the team. - Use PIs to partition the image. The good ol TFNR idea, which Ken now also expresses in his post. - Tie the PIs to corresponding SM entries. This is key to get the full connection to maintainers and their emails etc. - Gradually move to maintaining these "image packages" as MCs "released on SM", instead of using changesets in the stream. This part obviously is different from the recent plans in the Package team. - Add my planned dependency model in parallell with Universes. They in fact complement each other quite nicely when thinking more closely about it.
Now it seems like the plan is to move to using something independent of SM, which means I have no idea on how to proceed with the above. Perhaps I am not interpreting the plan correct - then you all may of course explain it to me and slap me. :)
I don't think that much has changed. I guess we're not talking, at the moment, about using SM as infrastructure for the maintenance of the core Squeak packages, but obviously it will continue to be used exactly as it is now, to manage the hundreds of external packages, and those need to be organized into stable sets of dependent versions as much as they ever did. So, I think we should keep to the plan of integrating Universes and dependencies into SM. It may be that once that's done we can look at how much overlap there is with the harvesting and releasing mechanisms we're talking about, and maybe do some further integration, but I don't think we'll really know that until we're further along. For now, I think it makes sense to keep them separate.
Avi
On Tue, 21 Jun 2005 15:00:01 +0200 , goran@krampe.se said:
Hi all!
(cross posting since Ken's recent post touches on the very same aspects)
Hi Goran & all, I'll cross-post for this one also since it affects all three groups. (I missed Ken's earlier post as I hadn't checked the Janitors list in a couple of days.)
I have been re-reading the archive (=the packages team archive) to see where we are and what I had promised to do. :) I am a bit unsure about the latest development.
If I understand everything correctly with the latest partitioning/iSqueak developments, I think your to-do items haven't changed too drastically... more below.
I had my sights set on this (brief description):
- Get Universes and SM playing together. As promised by me to Lex and
the team.
Still true. The iSqueak stuff is *only* relevant to the Basic packages making up the base image, not the Full packages or external packages. And we could still have Universes for the Basic packages.
- Use PIs to partition the image. The good ol TFNR idea, which Ken now
also expresses in his post.
Still very true, this is exactly what the iSqueak partitioning does, except the PI packages also happen to be MC packages, which have some big benefits IMO in terms of tool support.
- Tie the PIs to corresponding SM entries. This is key to get the full
connection to maintainers and their emails etc.
I think this is still true, and worthwhile. SM should still be the place to get maintainer names, email addresses and other miscellaneous meta-info for all packages, including Basic packages. Now, how exactly they are "tied" together I'm not sure... perhaps by naming convention (having the same name), or by virtue of the SM entry pointing to the same .mcz file, or something else.
- Gradually move to maintaining these "image packages" as MCs "released
on SM", instead of using changesets in the stream. This part obviously is different from the recent plans in the Package team.
Yes, this is the one part that is different. In the proposal, the idea is to simply have a special MC repository for the 3.9 release as it goes through alpha-beta-final, separate from the various master repositories for each package. (this repository is a sort of "configuration", similar to the Universe concept, actually) The alpha update stream gets the latest package versions directly from this MC repository rather than through SqueakMap.
The thing I really like about this is that the MC tools are there in the iSqueak image, showing you which package versions are in the image, you can browse the code for a package, and you can commit a new package version right there in the tool if you wanted to... no need to go to the SM website and upload your new version. For this sort of alpha stream/Basic package development with potentially lots of integration fixes, it seems like SM would add an extra layer which isn't strictly necessary. In any case, it works as-is right now, Impara is using it.
I was thinking that the final 3.9 Basic packages would all be on SM, of course, but that the interim 3.9alpha packages would not need to be. (unless a package owner felt like putting them out there)
Actually, maybe there is a way to work SqueakMap into this process, to unify things a bit more. Then perhaps the latest 3.9alpha "configuration" could be an SM universe instead, without requiring a special MC repository. As long as this was done in a way which did not affect the MC tools or make the development/integration process any more difficult, that might be good. That might be something to work on after we get this going.
But in any case, I think we're ready to try this proposal as-is right now, as there is no extra coding work to be done, it should work as soon as we set up a repository.
- Add my planned dependency model in parallell with Universes. They in
fact complement each other quite nicely when thinking more closely about it.
Yep, that still sounds good. AFAIK, there is not a dependency model within this iSqueak plan, it's simply an MC repository acting as a config map.
Now it seems like the plan is to move to using something independent of SM, which means I have no idea on how to proceed with the above. Perhaps I am not interpreting the plan correct - then you all may of course explain it to me and slap me. :)
Hopefully my replies above cover this? :) It is sort of independent of SM for now, but it's just the Basic image packages.
I have also some serious doubts about schemes/models that depend on "community work". With that I mean work "by" the community "for" the community, eh, if you know what I mean - instead of work "by" yourself "for" yourself. Hmmm, Ken has a much better english than me, but he is essentially saying the same thing.
Yes. This proposal is a big step away from the monolithic image and should rely less on "community work" than the current setup. In that respect I think it's not much different than the partitioning you had in mind. Most of the active package development should be done by the package owners in the master repositories for the packages, not in the 3.9 release repository. The 3.9 people would just assemble the latest packages which work together, and maybe occasionally work on some integration fixes (or get other people to do this).
Maintaining a release repository (or a Universe) is some work, but a lot less than maintaining everything as we do now. ;) Ok, it's a bit different than Universes, but you get the idea.
Harvesting is a typical example, an unselfish act for the good of all - not directly connected to any personal immediate need. Or trying to maintain a Universe, yes, I *do* have doubts about that model - but at the same time I want to enable it - because I may very well be wrong :).
Or staking out the image, an act which has stalled numerous times for that specific reason I think. All these activities have that in common - they are "non individual" activities relying on community members to do the work "for the benefit of all".
I have come to the personal conclusion that schemes depending on such work have a high risk of failure in the Squeak community. We simply aren't that good at it. We are much more individualistic and we like to scratch our own itches, which means there are two things we are really good at:
- Maintaining our *own* packages, typically driven by our own needs in
combination with pride and "feeling good" when other people appreciate your work.
- Finding and fixing bugs in other Squeakers' packages but almost
always driven by our *own* projects/packages, we simply fix stuff we stumble over.
So my view is that we need a system which relies on such individual work only, or at least to 95%.
Yep, I hope that would be true for this proposal.
Ken asked "What are we waiting for?" and... I am not sure. The PI-partitioning bit - which is key here - should simply "be done" IMHO. I say let's get *a single person* to just do it and push a .cs into the stream which creates the PIs. I was inclined to get Doug to do it (being v3.9 boss and all), but I don't really care as long as someone does it. Again, I am not sure how this plays with the latest plans/developments (read the packages archive for details).
It still fits in... I can add the partitioning changeset (from iSqueak) to the restarted 3.9alpha stream as soon as we have a SqueakSource/MC repository set up for 3.9.
- Doug
Hi guys!
"Doug Way" dway@mailcan.com wrote:
On Tue, 21 Jun 2005 15:00:01 +0200 , goran@krampe.se said:
I had my sights set on this (brief description):
- Get Universes and SM playing together. As promised by me to Lex and
the team.
Still true. The iSqueak stuff is *only* relevant to the Basic packages making up the base image, not the Full packages or external packages. And we could still have Universes for the Basic packages.
Sure, I agree basically, but see below.
- Use PIs to partition the image. The good ol TFNR idea, which Ken now
also expresses in his post.
Still very true, this is exactly what the iSqueak partitioning does, except the PI packages also happen to be MC packages, which have some big benefits IMO in terms of tool support.
Yes, I am aware of that - and agree, it is the same to the extent that PI is used.
- Tie the PIs to corresponding SM entries. This is key to get the full
connection to maintainers and their emails etc.
I think this is still true, and worthwhile. SM should still be the place to get maintainer names, email addresses and other miscellaneous meta-info for all packages, including Basic packages. Now, how exactly they are "tied" together I'm not sure... perhaps by naming convention (having the same name), or by virtue of the SM entry pointing to the same .mcz file, or something else.
There has been for a while a text field in SMPackage that simply names the PI. And this is even used today by the PI-changesets-extras-package that Ned has put together that among other things include some code from me.
- Gradually move to maintaining these "image packages" as MCs "released
on SM", instead of using changesets in the stream. This part obviously is different from the recent plans in the Package team.
Yes, this is the one part that is different. In the proposal, the idea is to simply have a special MC repository for the 3.9 release as it goes through alpha-beta-final, separate from the various master repositories for each package. (this repository is a sort of "configuration", similar to the Universe concept, actually) The alpha update stream gets the latest package versions directly from this MC repository rather than through SqueakMap.
The thing I really like about this is that the MC tools are there in the iSqueak image, showing you which package versions are in the image, you can browse the code for a package, and you can commit a new package version right there in the tool if you wanted to... no need to go to the SM website and upload your new version. For this sort of alpha stream/Basic package development with potentially lots of integration fixes, it seems like SM would add an extra layer which isn't strictly necessary. In any case, it works as-is right now, Impara is using it.
I agree that going straight to MC like you describe is perfect during development but I would have hoped that all packages in the released image do have "releases" on SM and do have SM counterparts. In other words - the above would be fine with me as long as we make proper SM releases at some points in time, like say we could do as Debian does - have a freeze period where we freeze package by package (=make SM releases) on our way towards the release of Squeak.
A situation where we have two different kinds of packages seems quite bad to me.
Use case: I want to see what versions of packages I have in my image, I go to the SqueakMap Package Loader and select "installed". Now, if there are *other* packages that don't show up then seems quite silly.
I can come up with tons of use cases where this division is A-packages and B-packages is bad.
And note that all I want is:
- That each PI package in the image has a corresponding SM package. - That we "tie" it using the PI name field (trivial). - That we do make SM releases at least at some points in time.
Doing intermediate MC releases during the whole development phase is perfectly fine. And I would also like to add a "Repository" field to SMPackage that points to the repository where other non-released versions can be found.
I was thinking that the final 3.9 Basic packages would all be on SM, of course, but that the interim 3.9alpha packages would not need to be. (unless a package owner felt like putting them out there)
See above. I think all should "be" on SM, but that doesn't stop anything AFAICT in this plan.
Actually, maybe there is a way to work SqueakMap into this process, to unify things a bit more. Then perhaps the latest 3.9alpha "configuration" could be an SM universe instead, without requiring a special MC repository. As long as this was done in a way which did not affect the MC tools or make the development/integration process any more difficult, that might be good. That might be something to work on after we get this going.
Yes, something like that. But as you say, nothing we need to decide now UNLESS the plan aims to use MC "configurations" or whatever - because then we are sidestepping SM in this area.
But in any case, I think we're ready to try this proposal as-is right now, as there is no extra coding work to be done, it should work as soon as we set up a repository.
- Add my planned dependency model in parallell with Universes. They in
fact complement each other quite nicely when thinking more closely about it.
Yep, that still sounds good. AFAIK, there is not a dependency model within this iSqueak plan, it's simply an MC repository acting as a config map.
Ok, I thought there was some kind of "configuration" thing going.
Now it seems like the plan is to move to using something independent of SM, which means I have no idea on how to proceed with the above. Perhaps I am not interpreting the plan correct - then you all may of course explain it to me and slap me. :)
Hopefully my replies above cover this? :) It is sort of independent of SM for now, but it's just the Basic image packages.
Ok, I would still very much for us to do as I described above - making sure there are SM packages for each of these packages (with PI filled in). That can't be a bad thing.
I have also some serious doubts about schemes/models that depend on "community work". With that I mean work "by" the community "for" the community, eh, if you know what I mean - instead of work "by" yourself "for" yourself. Hmmm, Ken has a much better english than me, but he is essentially saying the same thing.
Yes. This proposal is a big step away from the monolithic image and should rely less on "community work" than the current setup. In that respect I think it's not much different than the partitioning you had in mind. Most of the active package development should be done by the package owners in the master repositories for the packages, not in the 3.9 release repository.
The 3.9 people would just assemble the latest packages which work together, and maybe occasionally work on some integration fixes (or get other people to do this).
<
Maintaining a release repository (or a Universe) is some work, but a lot less than maintaining everything as we do now. ;) Ok, it's a bit different than Universes, but you get the idea.
Yes, but I still get nervous because it still sounds like a centralized plan somehow implying "a group of people doing work for all"-model which I am very scared of at the moment.
So my view is that we need a system which relies on such individual work only, or at least to 95%.
Yep, I hope that would be true for this proposal.
Ok. Good. Then we will just see where it goes.
Ken asked "What are we waiting for?" and... I am not sure. The PI-partitioning bit - which is key here - should simply "be done" IMHO. I say let's get *a single person* to just do it and push a .cs into the stream which creates the PIs. I was inclined to get Doug to do it (being v3.9 boss and all), but I don't really care as long as someone does it. Again, I am not sure how this plays with the latest plans/developments (read the packages archive for details).
It still fits in... I can add the partitioning changeset (from iSqueak) to the restarted 3.9alpha stream as soon as we have a SqueakSource/MC repository set up for 3.9.
Ok, can you get in contact with me as soon as this is done so that I can help us get SM packages in place?
- Doug
regards, Göran
On Wed, 22 Jun 2005 12:23:29 +0200 , goran@krampe.se said:
(snip)
- Tie the PIs to corresponding SM entries. This is key to get the full
connection to maintainers and their emails etc.
I think this is still true, and worthwhile. SM should still be the place to get maintainer names, email addresses and other miscellaneous meta-info for all packages, including Basic packages. Now, how exactly they are "tied" together I'm not sure... perhaps by naming convention (having the same name), or by virtue of the SM entry pointing to the same .mcz file, or something else.
There has been for a while a text field in SMPackage that simply names the PI. And this is even used today by the PI-changesets-extras-package that Ned has put together that among other things include some code from me.
Ah, I forgot about that. It makes sense to use that, then.
- Gradually move to maintaining these "image packages" as MCs "released
on SM", instead of using changesets in the stream. This part obviously is different from the recent plans in the Package team.
Yes, this is the one part that is different. In the proposal, the idea is to simply have a special MC repository for the 3.9 release as it goes through alpha-beta-final, separate from the various master repositories for each package. (this repository is a sort of "configuration", similar to the Universe concept, actually) The alpha update stream gets the latest package versions directly from this MC repository rather than through SqueakMap.
The thing I really like about this is that the MC tools are there in the iSqueak image, showing you which package versions are in the image, you can browse the code for a package, and you can commit a new package version right there in the tool if you wanted to... no need to go to the SM website and upload your new version. For this sort of alpha stream/Basic package development with potentially lots of integration fixes, it seems like SM would add an extra layer which isn't strictly necessary. In any case, it works as-is right now, Impara is using it.
I agree that going straight to MC like you describe is perfect during development but I would have hoped that all packages in the released image do have "releases" on SM and do have SM counterparts. In other words - the above would be fine with me as long as we make proper SM releases at some points in time, like say we could do as Debian does - have a freeze period where we freeze package by package (=make SM releases) on our way towards the release of Squeak.
Yes. I did mention that at a minimum we would have the 3.9 final packages released (or "published") on SM, and I forgot to mention that of course we should have the newly partitioned 3.8 packages on SM as well. And then, since there may be several months between 3.8 and 3.9, it might make sense to periodically release the current set of alpha packages to SM, if they are determined to be in a stable state. How often exactly, I'm not sure.
Also, keep in mind that this is just putting package sets on SM from the 3.9 "release repository". Each package should still have its own master repository, where core package development happens. The package owner might also be putting package versions from there on SM as well. (Hopefully there will not be issues with versioning numbering in MC with the two types of repositories. I haven't really used MC working across multiple repositories to know how it's handled. If it matters, I guess the based-on-iSqueak 3.9alpha image would list two repositories for every package in the MC Browser, the master repository and the release repository.)
A situation where we have two different kinds of packages seems quite bad to me.
Use case: I want to see what versions of packages I have in my image, I go to the SqueakMap Package Loader and select "installed". Now, if there are *other* packages that don't show up then seems quite silly.
Good point. We would not be adding brand-new named packages to the release repository (3.9alpha update stream) without also adding them to SM. (By this I mean a entirely new package, not a package version.) So, the only issue here would be that the SM Package Loader could possibly show an incorrect older version of a package that was updated via MC. But if you have the SM package point to the PI, perhaps the SM Loader could try to be "smart" about what is really in the image? Although, if the particular package version was a development version only in the MC release repository and not in SM, the SM Loader couldn't show an SM version, of course, perhaps it would just show the MC version. (The SM version numbers may end up mirroring the MC version numbers anyway.)
I can come up with tons of use cases where this division is A-packages and B-packages is bad.
And note that all I want is:
- That each PI package in the image has a corresponding SM package.
- That we "tie" it using the PI name field (trivial).
- That we do make SM releases at least at some points in time.
Agreed 100%. If we tie them together using the PI name field in the SM packages, that should work. (I don't think we want the PI itself to point to the SM package.)
So we agree on this.
As a side note, I'm not sure if this means that we may not need Ned's PI additions (for filing out PI's), if we're always using MC... I'm trying to remember exactly what the additions were. Although if they are generally useful and harmless, we could just add them.
Doing intermediate MC releases during the whole development phase is perfectly fine. And I would also like to add a "Repository" field to SMPackage that points to the repository where other non-released versions can be found.
Sure. I guess this would point to the "master repository" for the package, not the release repository.
...
Actually, maybe there is a way to work SqueakMap into this process, to unify things a bit more. Then perhaps the latest 3.9alpha "configuration" could be an SM universe instead, without requiring a special MC repository. As long as this was done in a way which did not affect the MC tools or make the development/integration process any more difficult, that might be good. That might be something to work on after we get this going.
Yes, something like that. But as you say, nothing we need to decide now UNLESS the plan aims to use MC "configurations" or whatever - because then we are sidestepping SM in this area.
Er, ah, um. Well, the update stream example Andreas gave did use MCConfiguration, so perhaps there is some duplication of effort here. Although that is only needed when a "config map" changeset needs to be added to the update stream to bring us up to a certain set of packages, in order to execute a DoIt changeset (to massage instances in the image for example), or if something must be loaded in a certain order.
But still, these configurations would only be within the alpha-development MC release repository, I believe. I'm not sure they could be extended to the world of packages out there, and in that sense I'm not sure they could compete with SM configurations.
Perhaps there is a way we eventually could replace the MCConfiguration command in the example update with an equivalent SqueakMap command, if all development package versions were on SqueakMap. But I'm not sure if it's worth the effort.
Stephane emailed me earlier saying that he was in favor of this MC partitioning plan, and that he thought of MC as more appropriate for package development, and SM for package deployment, which seems roughly right to me. And I think we're really talking about development here. But yeah, the concept of configurations/dependencies can apply to both, so there is some potential overlap. (I don't mind mentioning Stephane's private email on the list here as he is known to do the same thing. ;-) )
...
Hopefully my replies above cover this? :) It is sort of independent of SM for now, but it's just the Basic image packages.
Ok, I would still very much for us to do as I described above - making sure there are SM packages for each of these packages (with PI filled in). That can't be a bad thing.
Agreed.
...
The 3.9 people would just assemble the latest packages which work together, and maybe occasionally work on some integration fixes (or get other people to do this).
<
Maintaining a release repository (or a Universe) is some work, but a lot less than maintaining everything as we do now. ;) Ok, it's a bit different than Universes, but you get the idea.
Yes, but I still get nervous because it still sounds like a centralized plan somehow implying "a group of people doing work for all"-model which I am very scared of at the moment.
True. Only the cross-package changes (integration fixes and such) should have to happen in the centralized release repository. Hopefully most of the work will be decentralized in the individual packages by the maintainers working in their own repositories. (Actually, I can imagine detangling-type work would need to be done in a release repository and then fed back to the package owners.)
One cool thing about this plan, I think, is that if the centralized part of it completely falls apart for some reason, you'll still have all of the partitioned packages out there in individual repositories, with some versions on SqueakMap which you could still assemble via Universes or whatever, which wouldn't be too far from your original plan. (It might just take a really long time to put together a working 3.9 then. ;) )
So my view is that we need a system which relies on such individual work only, or at least to 95%.
Yep, I hope that would be true for this proposal.
Ok. Good. Then we will just see where it goes.
Yep. :)
... I can add the partitioning changeset (from iSqueak) to the restarted 3.9alpha stream as soon as we have a SqueakSource/MC repository set up for 3.9.
Ok, can you get in contact with me as soon as this is done so that I can help us get SM packages in place?
Yes, will do. It looks like Cees & Avi have the SqueakSource/MC repository nearly set up, then we can add the partitioning changeset to the restarted 3.9alpha stream.
- Doug
I have no time right now and just skimmed through the emails so I may be wrong.
I have the impression that goran is afraid that we manage squeak without using SqueakMap and that there is a competition with MC. This is not my view.
SM is not a tool to manage code, MC is. MC is not a tools for end-user that only want to easily access applications, SM is.
So I code and manage my code with MC and publish it using SM. Mixing the tools would mean that one will die and got frustration. So for squeak this should be the same.
Stef
Hi folks!
"Doug Way" dway@mailcan.com wrote: [BIG SNIP]
Also, keep in mind that this is just putting package sets on SM from the 3.9 "release repository". Each package should still have its own master repository, where core package development happens. The package owner might also be putting package versions from there on SM as well.
Mmm. That essentially means I should add the branch function to SM. But ok.
(Hopefully there will not be issues with versioning numbering in MC with the two types of repositories. I haven't really used MC working across multiple repositories to know how it's handled. If it matters, I guess the based-on-iSqueak 3.9alpha image would list two repositories for every package in the MC Browser, the master repository and the release repository.)
I think MC handles it fine. What I need to do with SM though is add the capability of branching I think. Otherwise things can get a bit confusing when upstream releases are mixed with tweaked versions from the "release repository".
A situation where we have two different kinds of packages seems quite bad to me.
Use case: I want to see what versions of packages I have in my image, I go to the SqueakMap Package Loader and select "installed". Now, if there are *other* packages that don't show up then seems quite silly.
Good point. We would not be adding brand-new named packages to the release repository (3.9alpha update stream) without also adding them to SM. (By this I mean a entirely new package, not a package version.)
Goodie.
So, the only issue here would be that the SM Package Loader could possibly show an incorrect older version of a package that was updated via MC. But if you have the SM package point to the PI, perhaps the SM Loader could try to be "smart" about what is really in the image? Although, if the particular package version was a development version only in the MC release repository and not in SM, the SM Loader couldn't show an SM version, of course, perhaps it would just show the MC version. (The SM version numbers may end up mirroring the MC version numbers anyway.)
Yes, I will fix this ASAP. SMLoader should then show the MC version and some visual que that the installed version is NOT an SM release. Hmmmm, let me think for a second... yes. Something like that.
I can come up with tons of use cases where this division is A-packages and B-packages is bad.
And note that all I want is:
- That each PI package in the image has a corresponding SM package.
- That we "tie" it using the PI name field (trivial).
- That we do make SM releases at least at some points in time.
Agreed 100%. If we tie them together using the PI name field in the SM packages, that should work. (I don't think we want the PI itself to point to the SM package.)
Not sure exactly what that means (not having the "PI point to the SM package").
So we agree on this.
As a side note, I'm not sure if this means that we may not need Ned's PI additions (for filing out PI's), if we're always using MC... I'm trying to remember exactly what the additions were. Although if they are generally useful and harmless, we could just add them.
You mean PackageInfo-Extras? That package includes several cool new menu actions for the changesorters of which I am proud of a few. :) They are very useful in a world of packages.
Hmmm, just playing with it and it seems I need to mail some FIXes to Ned (the mail to maintainers fails currently and I know why).
But anyway, really cool stuff in there! (After looking some more it seems Ned missed a few things when he integrated my stuff, I think I will have to sit down and do something about this.)
The coolest is that you can do cross package ENHs/FIXes in a single .cs and then just do "mail to maintainers including splits" in the changesorter and it will:
- Split the changeset by copying parts of it into separate changesets, one for each PI. - Locate SM packages for each PI and all maintainers (including co-maintainers) - Compose an email with both the original cs and all splits (one for each PI) and with the To: field filled with all maintainers/co-maintainers of all affected SM packages.
This way the maintainers of each affected package can view the full .cs to understand it and also see exactly what changes goes into their own package (and the others).
Now, *that* is cool, but after I posted this ENH a while back noone seems to have looked at it. ;)
Doing intermediate MC releases during the whole development phase is perfectly fine. And I would also like to add a "Repository" field to SMPackage that points to the repository where other non-released versions can be found.
Sure. I guess this would point to the "master repository" for the package, not the release repository.
Well... ehum. Right. I guess we need TWO such fields then. One for "upstream" (master) and one optional one for the "release" repo. Ok.
...
Actually, maybe there is a way to work SqueakMap into this process, to unify things a bit more. Then perhaps the latest 3.9alpha "configuration" could be an SM universe instead, without requiring a special MC repository. As long as this was done in a way which did not affect the MC tools or make the development/integration process any more difficult, that might be good. That might be something to work on after we get this going.
Yes, something like that. But as you say, nothing we need to decide now UNLESS the plan aims to use MC "configurations" or whatever - because then we are sidestepping SM in this area.
Er, ah, um. Well, the update stream example Andreas gave did use MCConfiguration, so perhaps there is some duplication of effort here. Although that is only needed when a "config map" changeset needs to be added to the update stream to bring us up to a certain set of packages, in order to execute a DoIt changeset (to massage instances in the image for example), or if something must be loaded in a certain order.
But still, these configurations would only be within the alpha-development MC release repository, I believe. I'm not sure they could be extended to the world of packages out there, and in that sense I'm not sure they could compete with SM configurations.
Perhaps there is a way we eventually could replace the MCConfiguration command in the example update with an equivalent SqueakMap command, if all development package versions were on SqueakMap. But I'm not sure if it's worth the effort.
Stephane emailed me earlier saying that he was in favor of this MC partitioning plan, and that he thought of MC as more appropriate for package development, and SM for package deployment, which seems roughly right to me. And I think we're really talking about development here. But yeah, the concept of configurations/dependencies can apply to both, so there is some potential overlap. (I don't mind mentioning Stephane's private email on the list here as he is known to do the same thing. ;-) )
Well, we will see where it goes.
regards, Göran
Am 23.06.2005 um 15:08 schrieb goran@krampe.se:
You mean PackageInfo-Extras? That package includes several cool new menu actions for the changesorters of which I am proud of a few. :) They are very useful in a world of packages.
Well, you know, changesets are *so* last millenium ;-) Honestly, I rarely look at a change sorter at all, and many of our student hackers don't even know what change sets are. Once you've switched to Monticello you'll surely experience the same.
Now, if those menu items would work with MC instead of changesets, that would be immensely cool! Like, create a .mcd instead of a .cs to mail to the maintainers.
- Bert -
This is nice to hear! After the post Ginsu time I was concerned that squeak community could not see the value of packages. So future is bright :)
On 23 juin 05, at 15:43, Bert Freudenberg wrote:
Am 23.06.2005 um 15:08 schrieb goran@krampe.se:
You mean PackageInfo-Extras? That package includes several cool new menu actions for the changesorters of which I am proud of a few. :) They are very useful in a world of packages.
Well, you know, changesets are *so* last millenium ;-) Honestly, I rarely look at a change sorter at all, and many of our student hackers don't even know what change sets are. Once you've switched to Monticello you'll surely experience the same.
Now, if those menu items would work with MC instead of changesets, that would be immensely cool! Like, create a .mcd instead of a .cs to mail to the maintainers.
- Bert -
goran@krampe.se wrote:
I have also some serious doubts about schemes/models that depend on "community work". With that I mean work "by" the community "for" the community, eh, if you know what I mean - instead of work "by" yourself "for" yourself. Hmmm, Ken has a much better english than me, but he is essentially saying the same thing.
Harvesting is a typical example, an unselfish act for the good of all - not directly connected to any personal immediate need. Or trying to maintain a Universe, yes, I *do* have doubts about that model - but at the same time I want to enable it - because I may very well be wrong :).
Or staking out the image, an act which has stalled numerous times for that specific reason I think. All these activities have that in common - they are "non individual" activities relying on community members to do the work "for the benefit of all".
Three ways to help here are: assign ownership, give credit, and make issues public. Ownership means if someone does something then it's final--they don't have to go through an approval process. The opposite, where three people have to sign off on something and where flamewars can erupt over the most trivial things, makes it very discouraging to contribute work. Credit means that the opening window and maybe the web site mentions the people who contributed. We should at *least* credit the release manager, and it would probably make sense to credit harvistors as well. Making things public is things like, marking which packages have open bugs. People prefer to do work if there is a publically visible result from it.
On the specific issue of harvesting, routing of bugs would help tremendously. The times I worked on harvesting I spent at least half of my time looking at old bugs that I wasn't qualified to help with. Routing can be done by direct manual assignment of a bug to a person, or by assigning bugs to packages.
Regarding the slow progress staking out the image, please remember that the little bit of experimenting we tried on this list went well. Yet, we decided to wait until later to move on it for real. I don't think we can draw any conclusions from the slow progress in partitioning, because the problem is that everyone is waiting on the Packages Group to say what to do and we haven't spoken up yet.
I have come to the personal conclusion that schemes depending on such work have a high risk of failure in the Squeak community. We simply aren't that good at it. We are much more individualistic and we like to scratch our own itches, which means there are two things we are really good at:
It's a risk, but let's be cautious how far we take the conclusion. Remember that some volunteer things do progress well for Squeak. For example, we get plenty of bug fixes submitted for the main image. Thus, let's just say that with a mostly volunteer effort, we cannot guarantee that any particular task is going to have enough volunteers.
That doesn't mean we give up on community projects. Aside from trying to make the quality degrade gracefully when any one task is not getting sufficient volunteers, we can also take the experimental approach: try something for a while, watch what happens, and then tweak it for the next release cycle.
Lex
packages@lists.squeakfoundation.org
-
Avi Bryant -
Bert Freudenberg -
Doug Way -
goran＠krampe.se -
Lex Spoon -
stéphane ducasse