Hi all. I'm the Coordinator assigned to this team... sorry I haven't actively participated until now, I just finished catching up with the list. (I know Goran is also participating, but I definitely need to do some coordinating here to make sure this work gets incorporated into 3.9.)
Hi!
Avi Bryant avi.bryant@gmail.com wrote:
On Tue, 8 Mar 2005 10:45:11 +0100, goran.krampe@bluefish.se goran.krampe@bluefish.se wrote:
Again, this presumes that we are focused on splitting. I would
very much
want us to stake out regardless of split work. In other words, let
us
throw a rough PI list on the Swiki (as you say) and let people
sign up
interest regardless if they immediately intend to hack on
splitting.
Sure, that's fine - if people would also like to declare interest in maintaining a package, as well as in doing immediate splitting work, that's clearly good information to record.
Ok, goodie. :)
Sounds good. Although looking at the swiki page:
http://minnow.cc.gatech.edu/squeak/5641
I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc.
Well, when talking about coarse vs fine-grained partitioning, I guess there are a few factors mixed into this... assigning maintainers, but also whether the subpackages are interrelated. But even with something like the "System" packages, which are sort of a grab-bag of random stuff, I wonder if we might be better off treating them as one big package for now, and trying to get someone who might prefer to support one section, to sign on instead as a co-maintainer for the whole thing.
Also, it would probably help a bit to beg on squeak-dev for more volunteers. :)
I happen to disagree with you about priorities: the most important thing, for me, is to enable the packages to be independently maintainable; only once that's possible, and once we've had a little bit of experience doing things that way, are real maintainers likely to emerge (or, for some packages, they won't - but that's interesting to know too). So by
all
Possibly. But I am betting we can get people signing up even though the pieces they are interested in are intermingled. :)
Well, I think both tasks are potentially difficult... doing the splitting but also finding maintainers for everything. I'd say let's get going with both tasks.
means let's start gathering information about who might want to Steward what, but I won't personally feel any real sense of progress until packages start taking concrete, accurate shape inside the
image.
Well, I am just cautious given earlier attempts that have stalled. :) And I also think that even intertwined packages would benefit from having clear assigned maintainers/stewards.
There's no real need to argue about this, since both can happen in parallel.
Exactly, no argument whatsoever. :)
Right. :)
But is anyone else interested in either of those things? The list as a whole has been pretty quiet. Maybe we're covering the wrong topics?
Well, I am all with you - but I agree it has been quiet.
Well, we may want to go back to squeak-dev to ask for "help"... there are probably people interested in specific packages who may not be following this (Packages) list closely.
A special stream is of course a way, but what are the reasons for
not
using the 3.9 alpha stream? If this is in order to get a quicker turnaround I think we instead could put one person as a special
reviewer
and then that person can feed it straight into 3.9alpha. Like Doug (being release manager) or you with the trust of Doug or whatever.
Well, I'm guessing we'll be doing some things (like categorizing huge swaths of methods as "*orphaned") that wouldn't be great for mass consumption; I'd feel better if we were in a private stream while starting this work, anyway.
Ok, I agree.
Hrrmmm, I also think that just using the 3.9alpha stream would make more sense. Give Avi direct access to the update stream, being one of the team leaders. (The Morphic Splitters team leader should also have access.) I was hoping to have a more open/optimistic approach to the update stream with 3.9, with more people having access.
(Has the private stream started up yet?)
Having a bunch of recategorizing going on in the main update stream might not necessarily be a big deal, the same code is still there, it's just the method & class categories changing. (Would there be that many methods changing to "*orphaned"? I'd think when in doubt, you'd leave them in current package (that the class is defined in) until you knew where they were going to go. In any case, moving stuff to *orphaned seems relatively low priority, and fairly harmless.)
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
So, then unless someone shouts Bloody Murder within a few hours :) then I would think we should move ahead with yourt plan - create the Swiki page, create a first shot at a list of PIs for current 3.9alpha and ask squeak-dev for people stepping forward for either split work or stewardship and sign up.
Ah ok, we can ask for more help then. :)
By the way, I agree with moving forward with PI as the format.
When we tried this the last time we ended up with trying to change the categories etc, and got stalled doing that - so my advice would be either to: a) Don't bother. Just throw together a list of PIs to begin with given the current 3.9alpha. b) Sit down yourself and whip together a changeset first and post that to your new updatestream. Don't bother discussing it here - just go. :)
Go Avi, go!
Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream).
- Doug
Hi guys!
Doug Way dway@mailcan.com wrote:
Hi all. I'm the Coordinator assigned to this team... sorry I haven't actively participated until now, I just finished catching up with the list. (I know Goran is also participating, but I definitely need to do some coordinating here to make sure this work gets incorporated into 3.9.)
Yup. :)
[SNIP]
Sounds good. Although looking at the swiki page:
http://minnow.cc.gatech.edu/squeak/5641
I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc.
Definitely. And as I have said, people can always divide further later on.
Well, when talking about coarse vs fine-grained partitioning, I guess there are a few factors mixed into this... assigning maintainers, but also whether the subpackages are interrelated. But even with something like the "System" packages, which are sort of a grab-bag of random stuff, I wonder if we might be better off treating them as one big package for now, and trying to get someone who might prefer to support one section, to sign on instead as a co-maintainer for the whole thing.
Yes, I think people are more likely to volunteer if they can co-maintain together with others.
Also, it would probably help a bit to beg on squeak-dev for more volunteers. :)
Indeed. But Avi has the ball now. ;)
I happen to disagree with you about priorities: the most important thing, for me, is to enable the packages to be independently maintainable; only once that's possible, and once we've had a little bit of experience doing things that way, are real maintainers likely to emerge (or, for some packages, they won't - but that's interesting to know too). So by
all
Possibly. But I am betting we can get people signing up even though the pieces they are interested in are intermingled. :)
Well, I think both tasks are potentially difficult... doing the splitting but also finding maintainers for everything. I'd say let's get going with both tasks.
And I say (yet again) don't get held up in refactoring. Let's just start pumping out 2-3 PIs so that we get this show on the road.
[SNIP]
But is anyone else interested in either of those things? The list as a whole has been pretty quiet. Maybe we're covering the wrong topics?
Well, I am all with you - but I agree it has been quiet.
Well, we may want to go back to squeak-dev to ask for "help"... there are probably people interested in specific packages who may not be following this (Packages) list closely.
Yes, definitely.
A special stream is of course a way, but what are the reasons for
not
using the 3.9 alpha stream? If this is in order to get a quicker turnaround I think we instead could put one person as a special
reviewer
and then that person can feed it straight into 3.9alpha. Like Doug (being release manager) or you with the trust of Doug or whatever.
Well, I'm guessing we'll be doing some things (like categorizing huge swaths of methods as "*orphaned") that wouldn't be great for mass consumption; I'd feel better if we were in a private stream while starting this work, anyway.
Ok, I agree.
Hrrmmm, I also think that just using the 3.9alpha stream would make more sense. Give Avi direct access to the update stream, being one of the team leaders. (The Morphic Splitters team leader should also have access.) I was hoping to have a more open/optimistic approach to the update stream with 3.9, with more people having access.
Yes, please, please. :)
(Has the private stream started up yet?)
Having a bunch of recategorizing going on in the main update stream might not necessarily be a big deal, the same code is still there, it's just the method & class categories changing. (Would there be that many methods changing to "*orphaned"? I'd think when in doubt, you'd leave them in current package (that the class is defined in) until you knew where they were going to go. In any case, moving stuff to *orphaned seems relatively low priority, and fairly harmless.)
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
Yes, I agree in full. Avi?
So, then unless someone shouts Bloody Murder within a few hours :) then I would think we should move ahead with yourt plan - create the Swiki page, create a first shot at a list of PIs for current 3.9alpha and ask squeak-dev for people stepping forward for either split work or stewardship and sign up.
Ah ok, we can ask for more help then. :)
By the way, I agree with moving forward with PI as the format.
When we tried this the last time we ended up with trying to change the categories etc, and got stalled doing that - so my advice would be either to: a) Don't bother. Just throw together a list of PIs to begin with given the current 3.9alpha. b) Sit down yourself and whip together a changeset first and post that to your new updatestream. Don't bother discussing it here - just go. :)
Go Avi, go!
Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream).
I would like to hear Avi's thought on how we handle the PIs, as classes or instances? There was a discussion around that earlier, and possibly classes is the way to go since our main tools (ChangeSets, MC) are centered around that. But I trust Avi to make that decision.
- Doug
regards, Göran
Hi all,
Sorry for being so quiet; I've been extremely busy (in fact, if it continues like this, I should probably step down as leader here, since it's silly to have a leader who takes a week to answer emails...).
Anyway, comments below...
I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc.
Definitely. And as I have said, people can always divide further later on.
If that looks like it will work better, great. We haven't had such a rush to sign up for pieces that I feel that list is set in stone; Doug, if you have a more granular set of packages in mind, please feel free to just change it.
Also, it would probably help a bit to beg on squeak-dev for more volunteers. :)
Indeed. But Avi has the ball now. ;)
I'm a little reluctant to ask for too much outside help until we have a better sense of what the task is, how well the tool support works, what good approaches to the problem are. I was hoping we would do a reasonable amount of work just with the people on this list first to establish that before begging for more people to get involved.
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
And I say (yet again) don't get held up in refactoring. Let's just start pumping out 2-3 PIs so that we get this show on the road.
I don't really know what "pumping out PIs" means, or at least what purpose it's supposed to achieve. It seems to me that something like "registering packages on SqueakMap" is much more meaningful, no? Which tools (apart from the PackageList that nobody uses for anything, and I think we agreed to drop) actually know or care with PackageInfo instances exist inside the image?
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
Yes, I agree in full. Avi?
Fine with me.
Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream).
I would like to hear Avi's thought on how we handle the PIs, as classes or instances? There was a discussion around that earlier, and possibly classes is the way to go since our main tools (ChangeSets, MC) are centered around that. But I trust Avi to make that decision.
I don't see a concrete place yet where introducing PI subclasses will help with the packaging work, especially given the init script stuff that Miso, Ned and I have been kicking around. So let's stick with instances for now.
Avi
Gee, didn't they tell you that when you took the job that you could only give it up if you died and you still need to give 2 years notice?
Hi all,
Sorry for being so quiet; I've been extremely busy (in fact, if it continues like this, I should probably step down as leader here, since it's silly to have a leader who takes a week to answer emails...).
Anyway, comments below...
I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc.
Definitely. And as I have said, people can always divide further later on.
If that looks like it will work better, great. We haven't had such a rush to sign up for pieces that I feel that list is set in stone; Doug, if you have a more granular set of packages in mind, please feel free to just change it.
Also, it would probably help a bit to beg on squeak-dev for more volunteers. :)
Indeed. But Avi has the ball now. ;)
I'm a little reluctant to ask for too much outside help until we have a better sense of what the task is, how well the tool support works, what good approaches to the problem are. I was hoping we would do a reasonable amount of work just with the people on this list first to establish that before begging for more people to get involved.
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
And I say (yet again) don't get held up in refactoring. Let's just start pumping out 2-3 PIs so that we get this show on the road.
I don't really know what "pumping out PIs" means, or at least what purpose it's supposed to achieve. It seems to me that something like "registering packages on SqueakMap" is much more meaningful, no? Which tools (apart from the PackageList that nobody uses for anything, and I think we agreed to drop) actually know or care with PackageInfo instances exist inside the image?
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
Yes, I agree in full. Avi?
Fine with me.
Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream).
I would like to hear Avi's thought on how we handle the PIs, as classes or instances? There was a discussion around that earlier, and possibly classes is the way to go since our main tools (ChangeSets, MC) are centered around that. But I trust Avi to make that decision.
I don't see a concrete place yet where introducing PI subclasses will help with the packaging work, especially given the init script stuff that Miso, Ned and I have been kicking around. So let's stick with instances for now.
Avi
Hi Avi!
Avi Bryant avi.bryant@gmail.com wrote:
Hi all,
Sorry for being so quiet; I've been extremely busy (in fact, if it continues like this, I should probably step down as leader here, since it's silly to have a leader who takes a week to answer emails...).
We will see. :)
Anyway, comments below...
I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc.
Definitely. And as I have said, people can always divide further later on.
If that looks like it will work better, great. We haven't had such a rush to sign up for pieces that I feel that list is set in stone; Doug, if you have a more granular set of packages in mind, please feel free to just change it.
I will start by contacting the names I know from before and see if I can get a few more of them to sign up.
Also, it would probably help a bit to beg on squeak-dev for more volunteers. :)
Indeed. But Avi has the ball now. ;)
I'm a little reluctant to ask for too much outside help until we have a better sense of what the task is, how well the tool support works, what good approaches to the problem are. I was hoping we would do a reasonable amount of work just with the people on this list first to establish that before begging for more people to get involved.
Sure, I try to follow whichever path you choose. :)
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
This is an interesting question. I am interested in doing partitioning work - but for me I think it is a priority thing - I would like to do the *stake out* first, and "ripping out" later. I explain below.
And I say (yet again) don't get held up in refactoring. Let's just start pumping out 2-3 PIs so that we get this show on the road.
I don't really know what "pumping out PIs" means, or at least what purpose it's supposed to achieve. It seems to me that something like "registering packages on SqueakMap" is much more meaningful, no? Which tools (apart from the PackageList that nobody uses for anything, and I think we agreed to drop) actually know or care with PackageInfo instances exist inside the image?
Ok, let me explain (I know Avi knows this stuff, but perhaps there are others on this list).
SM has a PI field for each package. Using that (as most of us already know) we can map an SM package to an in-image PI. Today there are just a very few of those mappings - for example for SM itself. What is the mapping for? It is the link between the code (classes and extension methods) and the SM entry. Given that this link exists we suddenly *know* who maintains that code (email) and any co-maintainers of it.
For example, given the PI-extras package in which Ned has included my PI-split-and-email-to-SM-maintainers-mechanism, a user can:
1. Fix a bug or add an enh. 2. Bring up a changesorter on that cs. 3. With a single menu choice split it up into one cs for each affected PI and send those (plus the original complete cs) as an email to *all* maintainers of those SM packages affected.
Now... this mechanism is of course a bit crude, but imagine that *all* code in the image belong to a PI - then suddenly using the above mechanism (or similar) we could actually decentralize the complete FIX/ENH process. And we could use MC instead of changesets etc. Suddenly we have a structure to work in.
So in short - I want this to happen:
1. Create rough PIs in Basic (using some updates in 3.9a) that cover the *complete* image. In whichever granularity. We can always adapt them later.
2. Create corresponding SM entries for them, typically this is done by the maintainers stepping forward. If some are left as orphans, lets create some SM packages anyway and let a team of maintainers for the orphans sign up on that package. The important thing is that each line of code in the image can be mapped to 1-n maintainers.
3. Let the maintainers start working. This entails: 1. Adding/removing PIs (using updates) in order to further split/combine code. 2. Reorganize, typically classes and methods will have ended up in the wrong PI. 3. Refactor, this is modifying code to decouple stuff with the intention of making code loadable/unloadable.
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
Yes, I agree in full. Avi?
Fine with me.
Good!
Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream).
I would like to hear Avi's thought on how we handle the PIs, as classes or instances? There was a discussion around that earlier, and possibly classes is the way to go since our main tools (ChangeSets, MC) are centered around that. But I trust Avi to make that decision.
I don't see a concrete place yet where introducing PI subclasses will help with the packaging work, especially given the init script stuff that Miso, Ned and I have been kicking around. So let's stick with instances for now.
Ok, instances it is.
Avi
regards, Göran
On Mon, 4 Apr 2005 11:25:09 +0200 , goran.krampe@bluefish.se said:
Hi Avi!
Avi Bryant avi.bryant@gmail.com wrote:
Hi all,
Sorry for being so quiet; I've been extremely busy (in fact, if it continues like this, I should probably step down as leader here, since it's silly to have a leader who takes a week to answer emails...).
We will see. :)
Yes, we will only let Avi step down if someone else eagerly volunteers. ;)
If that looks like it will work better, great. We haven't had such a rush to sign up for pieces that I feel that list is set in stone; Doug, if you have a more granular set of packages in mind, please feel free to just change it.
Ok, will do. Basically I am just going to consolidate "Network", "Tools" and "System" into three big packages. Then the maintainers of those packages can work on splitting them up inside later. I see a few people have already signed up for sub-packages of those, I will list them as comaintainers of the big packages, with a small note specifying which sub-package(s) they're interested in.
...
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
This is an interesting question. I am interested in doing partitioning work - but for me I think it is a priority thing - I would like to do the *stake out* first, and "ripping out" later. I explain below.
I generally agree with Avi that I think we can do both at the same time. I think the "stake out" (assignment of maintainership) might not be that easy to finish, so we may want to move forward with *some* partitioning, which will give us some time to get our process and package-related tools working. Then, as people see that the process is actually moving forward, there may be more interest from people in taking on maintainership.
Perhaps we should at least have a rule, though, that a particular package should be staked out by some maintainers before it is partitioned. (and certainly before it is removed)
Anyway, regarding maintainership, I have three words: Redundancy, redundancy, redundancy. :-) I think it's critical to have multiple maintainers for each Basic package. It's inevitable that people will have varying amounts of time to maintain a package, so we need a co-maintainer(s) to step in when someone else drops out of sight for a while. I think we should have a rule that each Basic package should have at least three maintainers, including one lead maintainer. (Well, maybe bend the rules a bit for a few lesser-used packages such as Speech if we have to, but I think it's a good rule.)
This is another advantage of consolidating the packages into bigger ones, btw... it's easier to find multiple maintainers and have this redundancy of maintainership.
And I say (yet again) don't get held up in refactoring. Let's just start pumping out 2-3 PIs so that we get this show on the road.
I don't really know what "pumping out PIs" means, or at least what purpose it's supposed to achieve. It seems to me that something like "registering packages on SqueakMap" is much more meaningful, no? Which tools (apart from the PackageList that nobody uses for anything, and I think we agreed to drop) actually know or care with PackageInfo instances exist inside the image?
Ok, let me explain (I know Avi knows this stuff, but perhaps there are others on this list).
SM has a PI field for each package. Using that (as most of us already know) we can map an SM package to an in-image PI. Today there are just a very few of those mappings - for example for SM itself. What is the mapping for? It is the link between the code (classes and extension methods) and the SM entry. Given that this link exists we suddenly *know* who maintains that code (email) and any co-maintainers of it.
For example, given the PI-extras package in which Ned has included my PI-split-and-email-to-SM-maintainers-mechanism, a user can:
- Fix a bug or add an enh.
- Bring up a changesorter on that cs.
- With a single menu choice split it up into one cs for each affected
PI and send those (plus the original complete cs) as an email to *all* maintainers of those SM packages affected.
Now... this mechanism is of course a bit crude, but imagine that *all* code in the image belong to a PI - then suddenly using the above mechanism (or similar) we could actually decentralize the complete FIX/ENH process. And we could use MC instead of changesets etc. Suddenly we have a structure to work in.
So in short - I want this to happen:
- Create rough PIs in Basic (using some updates in 3.9a) that cover the
*complete* image. In whichever granularity. We can always adapt them later.
- Create corresponding SM entries for them, typically this is done by
the maintainers stepping forward. If some are left as orphans, lets create some SM packages anyway and let a team of maintainers for the orphans sign up on that package. The important thing is that each line of code in the image can be mapped to 1-n maintainers.
- Let the maintainers start working. This entails:
- Adding/removing PIs (using updates) in order to further
split/combine code. 2. Reorganize, typically classes and methods will have ended up in the wrong PI. 3. Refactor, this is modifying code to decouple stuff with the intention of making code loadable/unloadable.
This all sounds exactly right... I think we are on the same page here.
A related issue is how soon after PI-partitioning should the package actually be removed from the base image and have its master version stored on SqueakMap. Basically, I don't think we should move *too* fast with that. But I'll address that in a separate email.
Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute.
Yes, I agree in full. Avi?
Fine with me.
Good!
Ah, good. And I think it's not a big deal if we make a few mistakes along the way and fix them as we're doing this... it is the alpha release after all.
I would like to hear Avi's thought on how we handle the PIs, as classes or instances? There was a discussion around that earlier, and possibly classes is the way to go since our main tools (ChangeSets, MC) are centered around that. But I trust Avi to make that decision.
I don't see a concrete place yet where introducing PI subclasses will help with the packaging work, especially given the init script stuff that Miso, Ned and I have been kicking around. So let's stick with instances for now.
Ok, instances it is.
Very good. (I was hoping we were going with instances, actually.)
- Doug
[apologize if you get this twice, I was having mail problems]
Avi Bryant wrote:
I'm a little reluctant to ask for too much outside help until we have a better sense of what the task is, how well the tool support works, what good approaches to the problem are. I was hoping we would do a reasonable amount of work just with the people on this list first to establish that before begging for more people to get involved.
Definitely understand the sentiment, but I think there's a deeper problem here.
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
Well, what are our goals? seems to me like the partitioning work is not good for itself - it supports (or should support) use cases.
Some obvious kinds of use cases are: 1. "I want to be able to strip my images of this part" (MorphicSplitters) 2. "I want to be able to swap in an alternative implementation" (ToolBuilder) 3. "I want to develop/maintain this outside the image" (Celeste, when I started doing it)
I, BTW, was under the impression that at least part of our goal here was to support the people doing the partitioning, rather than do it ourselves (though walking a mile might be a good idea anyway). I'm here to do tool support, in and around the MudPie area.
For that we should have "meta" use cases, that are not specific to one piece of the image, that should give us extra capabilities towards whatever code in the image is well packaged. Some examples. I should be able to: (anyone) 1. See the packages, including dependencies, in the standard browser. 2. Remove packaged code with a click or two. 3. Develop as a package and share my code with no extra hassles (for example, starting from a d/led image, I modified PackageInfo. Because I didn't declare it as a package at the start, when I saved it, it had no parentship information in MC). (developer affecting code structure) 4. Have tool support when I'm improving my packages internal dependencies, and relations with the outside world. 5. Make it really clear when one is working on packaged stuff, versus working on the Ball of Mud. 6. Have any improvement/deterioration in the structure of the code in my image immediately give the user/community usable feedback, so that things move in the right direction henceforth.
So obviously I'm mostly interested in helping concretely with (4-6), and think these are important, because until they are in place, things will not really improve. But generally:
What usecases (from either of the lists above or otherwise), do people on this list want to work on?
Daniel
Daniel Vainsencher danielv@tx.technion.ac.il wrote: [SNIP]
So let me beg here instead: who is actually interested in doing partitioning work? Anyone? Is this just something that we care about more in the abstract than in practice, and nobody really wants it enough to do it? Are there other ways we should be thinking about this that would get more traction? (like, "how many bits of code can we package up and unload from the image?")
Well, what are our goals? seems to me like the partitioning work is not good for itself - it supports (or should support) use cases.
Some obvious kinds of use cases are:
- "I want to be able to strip my images of this part" (MorphicSplitters)
- "I want to be able to swap in an alternative implementation"
(ToolBuilder) 3. "I want to develop/maintain this outside the image" (Celeste, when I started doing it)
And IMHO:
4. "I want to have the image staked out with maintainers assigned so that we have 'owners' of the code."
This #4 doesn't imply 1, 2 or 3. It is useful all on its own.
[SNIP]
What usecases (from either of the lists above or otherwise), do people on this list want to work on?
I will get back to you on that one. No time at this minute. :)
Daniel
regards, Göran
goran.krampe@bluefish.se wrote:
And IMHO:
- "I want to have the image staked out with maintainers assigned so
that we have 'owners' of the code."
This #4 doesn't imply 1, 2 or 3. It is useful all on its own.
Even if its independent of the first 3, I think its a bit abstract. I think if you wrote some use cases for it, there'd be a better chance that it will happen. IIUC, one that you want is: - User creates a changeset. When he publishes it, it gets split on package boundaries, appropriately exported, and mails get sent to the appropriate people.
What else do you have in mind?
Daniel
And IMHO:
- "I want to have the image staked out with maintainers assigned so
that we have 'owners' of the code."
This #4 doesn't imply 1, 2 or 3. It is useful all on its own.
FULLY AGREED. This lets people specialize in parts of Squeak, which helps with (a) answering questions anyone might have about that part, and (b) processing bugs and patches posted against that part.
The first use case I have in mind is this one:
CASE: Bob sends an FIX which causes FileUrl to properly parse URL's with three slashes in them. This FIX gets included into the Squeak distribution.
Partitioning + assignment of maintainers, implements this use case as follows. Jill (say) is assigned as maintainer for the URL package. Jill knows that package fairly well, and can determine that the submitted fix is a good one. Jill proclaims the fix to be a good one, and this is enough that the fix goes into the pipeline for being included in the Squeak distribution. (This might be as simple as giving Jill write access to the official version of the URL package--she can update it whenever she wants).
A second use case, is that Bob finds a bug but does not know how to fix it. He sends his bug report to Jill, who is in a perfect position to choose the next step forward due to her familiarity with the package. Partitioning plus maintainer-assignment means that the Bob and Jill can easily find each other and start communicating.
-Lex
packages@lists.squeakfoundation.org
-
Avi Bryant -
Daniel Vainsencher -
Doug Way -
goran.krampe＠bluefish.se -
John Pfersich -
Lex Spoon