proposal for starting work on partitioning

[goran.krampe at bluefish.se]

Hi!

Avi Bryant <avi.bryant at gmail.com> wrote:
> Cees and I just chatted on IRC about tools for supporting
> partitioning, and coordinating between the package splitting we do and
> the work done by the morphic splitters.  Here's the simple proposal I
> have to let us get started as quickly as possible, hopefully with
> minimal conflict and minimal need for coordination:
> 
> - I'll set up a page on the swiki with a list of packages in the image
> (if people have string preferences for how granular to make this list,

Ah, you mean "strong". Took a while to parse. :)

> or what should be on it, please say so).  To begin with they'll all be
> up for grabs except the morphic ones.

Personally I think we can rely on further "cell division" by the
Stewards themselves, so we don't need to be too fine granular nor exact.
I think you could simply dump a first rough list and then we go from
there either dividing or merging further.

> - If you want to do some work on splitting out a package you put a
> note beside it on the wiki saying that you've started working on it
> and what the current date is.
> - When you've done some work on it and are stopping, post a changeset
> with what you've done to the list, and take your name off of the page.

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.

But again, that was perhaps your idea, I might be misinterpreting.

> - I'll post the changeset to a special update stream as soon as
> possible so that people can easily stay in sync.  Always try to update
> from the stream before starting to work on your own splitting.

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.

> - If someone's had a package "checked out" for a while without
> posting, use your judgement as to whether or not to override their
> lock and work on it yourself - maybe email them to see if they'll
> release the lock to you, or post to the list about it.

Reasonable. But again, signing up as an interested Steward on a PI
should be doable regardless of splitting effort IMHO. I think splitting
will take a looooong time and we should IMHO not let that stop us from
performing the stakeout.

> - In terms of how we attack the splitting itself, it seems to me that
> it's easiest if people can really just focus on one package at a time
> - that is, I want to look through all the methods of a package and
> just decide "is it in this package or isn't it".  So I suggest that we
> work in two passes: first, we try to kick everything out of packages
> that shouldn't be there, by going through all of the classes in the
> package and moving any of their methods that shouldn't be in the
> package to a special "Orphaned" package.  Second, or in parallel, we
> go back through the Orphaned methods and adopt the relevant ones into
> our package.  It would be nice if we had some tools to go through
> lists of methods in a package, or in Orphaned, with big "Mine" and
> "Not Mine" buttons, but we can probably do without that for now.

Sounds like a good approach.
 
> If this approach seems sensible to people, I'll set up the small bits
> of infrastructure required right away.

Well, Göran-the-broken-record would like to again voice the opinion that
we should try to find Stewards for the PIs and register corresponding SM
packages ASAP. And not let the splitting stop us. :)

> Avi

regards, Göran