goran at krampe.se wrote:
> (warning - long post - but possible containing some good info and
> thoughts)

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 
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
> though.

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.

Cheers,
   - Andreas