proposal for starting work on partitioning

[goran.krampe at bluefish.se]

Hi guys!

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 
> 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