proposal for starting work on partitioning
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Wed Mar 30 09:20:02 UTC 2005
Doug Way <dway at 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
> Sounds good. Although looking at the swiki page:
> 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
> 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.
> > > 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.
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
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
More information about the Packages