History and thoughts about "how" we work on the image together
stephane.ducasse at gmail.com
Sun Oct 8 11:36:41 UTC 2006
We did what we did because we tried to still make the system move
forward in presence of ghost team.
> 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...
>> 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
>> 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 release?
> 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
>> "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.
> - Andreas
More information about the Squeak-dev