I agree.
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
>> 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
>