I read the blog of cees and it reminds me the post of someone  
thinking aloud but not
really actually doing something to improve the situation. Blogging is  
so easy.


> 1. In the beginning we had SqC, a tight team with full time dedicated
> people. A few of the SqCers (Ted and Dan IIRC) worked as update stream
> maintainers and did most "harvesting". It worked probably because  
> of the
> limited scale and the dedicated time. And because SqC held the rudder,
> there was not much discussion going on. There were negative sides of
> course - but if we focus on the actual work made on the image, this
> model probably worked quite ok given the circumstances at the time.
> After all, it is a classic model - a few people in control and most
> others sending contributions that may or may not be accepted.

Sure I think with 5 people payed full time we could do a lot.


> 3. As a response to this (the seemingly unsustainable harvesting  
> model)
> an new model formed that is based on dividing the image into different
> parts (using PackageInfo that came about when Monticello was built)  
> and
> then trying to get people to take personal responsibility of those  
> parts
> ("Stewards") and form smaller development teams around them. Most  
> of us
> saw this as the only way forward - and we also recognized that this  
> was
> the way that all the "rest" of the Squeak artifacts are maintained  
> (see
> 666 packages on SM) - so why shouldn't it work also for the parts  
> in the
> image?
>
> With 3.9 this partitioning is now official since the 3.9 release team
> took the partitioning and ran with it. A good move IMHO, but... (there
> is always one, isn't there?)

I do not understand your sentence above so I will not reply.

> ...developers haven't really *flocked* to the different parts and the
> small teams we all wanted to see haven't flourished. The 3.9 team  
> ended
> up acting more like harvesters than integrators. So the theory sounds
> good - but the practice isn't following. Why is that so?

Indeed!

> Perhaps it is simply because we haven't "pushed" this model enough in
> the community. Are people aware that there now are different packages
> waiting for Stewards to take them on? Are people aware of what that
> means? Do we even have this model defined and described a little bit?
> No.

Exact.

> So that is surely one of the reasons. But is it really the only one  
> - a
> lack of "marketing"?
>
> I think there is at least one more reason. I think that the simple  
> fact
> is that a lot of the work on the base packages are done as "side
> effects". Things you stumble on while you are writing the next Seaside
> or whatever. Things that have bugged you for a long time and suddenly
> you just fire up a browser and try to fix it. Try to scratch that damn
> itch!
>
> At least bug fixes and small enhancements come about this way I am
> pretty sure. So the same people that typically do these small fixes,
> possibly all over the place, can't really sign up for each and  
> every PI
> of the image. And most of these people are also pretty busy so just
> signing up for one of these PIs is a "step" that is easiest not taken.
>
> Just looking at myself - yes, I want to help with IO, Collections,  
> a few
> tools and probably a bit here and there related to packages I try to
> maintain. And yes, I did join the IO team when this was fresh - but
> alas, even *I* have dozed off.

Indeed. Doing something regularly a little at the time but steadily  
is really difficult.

> So if the vision of "permanent" teams around a Steward for specific
> parts of the image fails because of the fact that people aren't that
> focused or have that amount of time or interest (or whatever the  
> reason
> is) - are there other ways to organize ourselves?
>
> I don't have a clear "package" to offer. :) But I do think we can fix
> some problems at least:
>
> 1. The Easy Contribution.
>
> Now, is it *easy* for someone to "share" a fix or enhancement? Is it a
> single button to push? Is it obvious how to do it? Can a newbie do it?
> Is the mental barrier low enough or is sharing a fix connected with a
> bunch of prerequisites like code quality, unit tests etc that makes it
> seem "hard work" to do it? Have you ever skipped sending in a fix
> because it just felt like a bit too much work at the moment you  
> made the
> fix? Truthfully? :)

Send a fix to who?


> Earlier it was kinda easy. You picked the changesorter, sliced out  
> your
> fix, wrote a preamble and fired it off with a "mail to list". You knew
> that perhaps it would not be picked up, perhaps not - but at least  
> this
> first step was easy. And yes, we drowned in such contributions and
> suffered from lack of harvesting - but that is still the second step -
> the first step seemed to work pretty ok.
>
> Today it is *almost* as easy. We still use changesets for fixes  
> etc, but
> we upload to a Mantis installation instead. It gives better  
> tracking and
> so on, but the steps to create an issue etc is more complex. You  
> need to
> get an account and figure out what to write in various fields and  
> so on.
> But sure, it is still fairly easy. I bet we could make it even easier
> though.

At least this is rationalized (I do not find my babies inside Mantis  
but I like the infrasttructure
it represents).

> 2. The Bleeding Edge.
>
> Today we really don't have a bleeding edge. This is an idea that has
> been around in various shapes and forms, a separate alpha update  
> stream
> or whatever. This is also what most other "more conventional" OSS
> projects have - the CVS/SVN or whatever repository. The classic  
> model is
> to have trusted developers that can just "commit" straight onto a
> bleeding edge - and then it gets gradually frozen, tested, distilled,
> reviewed or whatever when the times come for a release.
>
> Our corresponding bleeding edge today would be a range of MC repos  
> which
> you would need to track and manually pull snapshots from - for each
> package in the image. There are many. And the snapshots typically
> interdepend on each other so you just can't pull the latest from them
> all.
>
> I bet that if we had the official image available in a similarly  
> "easy"
> way as a single CVS/SVN repo - it would be much easier for  
> developers to
> engage. Doesn't this idea go against the partitioning idea? Yeah,
> probably. But perhaps we can make them live side by side!
>
> Consider if we just set such a thing up and let developers "go wild".
> The maintainers of each separate piece could then track this thing and
> "shout" if they saw something go astray. Or simply roll back or "fix"
> changes that missed the mark. And they could then take "sanctioned"
> snapshots of their each package and put that in a repo.

Have a serious look in the inbox of the squeakfoundation source to  
see that
it cannot work. What can work is that you have a guy responsible of  
package that sorts the
stuff he wants to get in. The main problem is cross cutting changes.  
because you need several
packages to be in sync.

Stef