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(a)gmail.com> wrote:
> > On Tue, 8 Mar 2005 10:45:11 +0100, goran.krampe(a)bluefish.se
> > <goran.krampe(a)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
