[Squeakfoundation]RE: Your stewardship(s)

[goran.hultgren at bluefish.se]

Hi guys!

(Damn, 157 unread monday morning - hmmm, this is almost getting hard to
keep up with. Just so you know, I read sqf first carefully and then
maybe a bit more lax on squeak-dev. IMHO the traffic there is getting a
bit... well, quite a few posts with not so much content. But hey, that
is unavoidable as the community grows)

"Andreas Raab" <andreas.raab at gmx.de> wrote:
[BIG SNIP of stuff I agree/understand/whatever]
> Most problematic at this point is that there is no API for any of the
> package that a client can rely on, no dependencies, versions etc. In the

Yes, true. But versions and dependencies are coming. And with them the
little idea of mine with "backwards compatibility level" of a package
release could hopefully remedy the lack of a declared API.

> days of the monolithic image that wasn't as big a problem as you could
> simply browse all the senders of some class/message to see where it's used.

Yeah, that is a "problem" I also have been thinking about. Perhaps
someone could set up some form of server somewhere that maintains
indices of senders/implementors and in which package release they are.

Then you could send some sortof of simple query over to that server and
get a result back. This would at least make it easier, you could see if
someone uses a specific method at all - or what package releases do.

[Hmmm, it feels like I am always proposing some new infrastructure of
some kind...]

> With SM, we need a more declarative style that tells both, clients and
> framework developers which methods can be relied upon and which can't.
> Without this, maintaining a package simply becomes a nightmare.

Are you sure? I mean, don't you think a little bit of documentation on a
package might suffice? So that it is obvious what classes/messages are
meant to be used from outside? And if we combine this with a more unit
test centric model perhaps it would be enough.

Anyway, then we get to the interesting bit:

> <off-topic>
> Perhaps as some additional food for thoughts, if I think about the form in
> which I could imagine to be a steward/maintainer for some aspect of Squeak
> it immediately comes to my mind that the first and faremost issue is that of
> enabling _others_ to be able to work on that same package. Since all of us
> have only a limited amount of time I think it is critical that more than one
> person is responsible for a particular package. One way in which I could
> imagine this, is by essentially giving each package its own update stream
> which is used for the developers of some package. In this case, any of the
> developers would be able to post and review changes that are done in this
> area, and "releases" mean only that the incremental updates are merged and
> put out as package at SM.
> 
> Of course, this requires trust in the developers working in a particular
> area, but this could then be the primary task of the Steward - to identify
> developers both interested and capable of working in this area. The
> essential model would be that the community (represented by the guides)
> hands their trust into the Steward and the Steward hands this trust to the
> group of developers involved. Whether the Steward herself hacks along with
> the developers is quite a different matter; she would simply be the person
> ultimately responsible for some package. So that feature requests, bug
> fixes, blames would rightfully go to the Steward and from there be relayed
> to the developers involved. Conceptually, SourceForge is not a bad model for
> this - it allows registered developers to participate in projects for which
> they need blessing by one of the admins of that project. In Squeak terms,
> the initial admin for one of these projects (packages) would be the steward
> and from there, more people could join in.

Right. I think all this sounds... well, "perfect" is the word popping
up. And this is also how I have "envisioned it" inside my head - though
I haven't written it down as nicely as Andreas has here. The point
anyway is that being a Steward does definitely not mean that it is a
oneman job. Delegation, delegation, delegation.

Accidentally KCP (SCG) seems to have adopted something similarly with
Alexandre Bergel as the appointed Steward/front man.

And btw, I like keeping toolchoices open as much as possible (for
example the package format agnosticism in SM) so IMHO a Steward is free
to pick and choose how a particular package is maintained (source
sharing, update stream, Monticello, DVS/CVS, autoslurped from a Swiki
;-) whatever makes that Steward happy).

The only thing we could try to standardize is how a bug/fix or enh is
"posted". IMHO a ChangeSet is still the most "capable" format and email
is a very simple transport (with a bunch of advantages).

We could very easily in SM1.1 add an email address field to a package
where bug reports/fixes/enhs are received. And if we adopt some very
simple standard of noting which package the post is for, we could easily
setup a new mailinglist on sqf that ONLY is used for this. For some time
I have been thinking that all those posts really could be on a separate
list.

Anyway, enough blabbering - I like Andreas "write up" and really think
this is the "expectation" we should place in a Steward and nothing more.
If nobody helps her doing the job then it isn't her fault - she only
agreed to hold the rudder, if the oarmen don't show up...

And btw, I think it is *VERY* important for the community - as we are
reshaping ourselves here - to take it a little bit slow. We *DO NOT*
want to end up in a situation where seasoned Squeakers don't feel like
participating anymore - we simply must make sure that we still are
*HAVING FUN*!


regards, Göran