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