History and thoughts about "how" we work on the image together
andreas.raab at gmx.de
Sat Oct 7 21:10:15 UTC 2006
goran at krampe.se wrote:
> (warning - long post - but possible containing some good info and
Interesting post. Couple of comments:
> 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?)
> ...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?
I think it's simply because the 3.9 team never understood itself as an
integrator of externally maintained packages. Instead of delegating
fixes to the appropriate maintainers and waiting for those fixes to be
turned around they added them directly to the image. I can understand
why they did it (it's a lot faster to push this stuff directly) but when
it comes to enabling others this is a plain slap in the face.
Personally, I think that the only way to make progress in this matter,
to really enable and to push the maintenance issue, is to make the
community feel that actions have consequences. As long as the release
team will do the work for everyone they'll only burn out with little
positive effect overall. But what if there wouldn't be a single change
in Morphic in 3.9 because there isn't a team which has delivered a
Morphic package for the release? What if the fixes to Files and Sockets
are missing because there isn't an I/O team delivering a package for the
I think you'd *very quickly* find a few people who find that they have
at least enough time to fix and integrate a bug here and there. And that
is a starting point, people grouping around that package to fix a bug
here or there.
> 1. The Easy Contribution.
[... snip ...]
> 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
I know that people bitch and moan about Mantis but all I can say is that
compared with the alternatives, Mantis is hugely advantageous. Even the
threshold to post a bug is good in my understanding. It makes sure that
if you go to the length of reporting a bug (and it's really not *that*
much effort) you try to provide good and accurate information. 9 out of
10 bugs that I come across are clear, obvious, and for those that come
with a fix the fix is usually just fine the way it is. Meaning I can
avoid sifting through tons of unrelated emails (the BFAV problem) and
focus on solving or integrating the fixes. In other words, lowering the
bar is not necessarily advantageous.
> 2. The Bleeding Edge.
[... snip ...]
> 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.
I don't think so.
More information about the Squeak-dev