Hi Andreas and all!

Andreas Raab <andreas.raab at gmx.de> wrote:
> goran at krampe.se wrote:
> > 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.

I would guess that the 3.9 team disagrees :) - but it doesn't matter -
what matters is how we go forward from here.

Do we believe in the model? Will the next release team (3.10 or 4.0 or
both in parallell :)) work differently? Do we need to create some team
(or appoint a role in the current board at least) to get these teams
going - like explaining it more, trying to help people form teams etc?
Should we focus on central infrastructure for these teams or let them
"spread" any way they like? And so on.

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

Yeah, it might work. We would of course get a "breather" period while
teams get formed, but for the next release that might not be a bad idea.
Robustness, bug fixing, cleaning might be what we should focus on
anyway.

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

I don't :). I was just comparing the "Easyness" of making the
contribution. As we are totally in agreement with, we need an issue
tracker of course.

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

I agree with your points too. I am just afraid that we are missing lots
of "small fixes" because people don't take the time. I might be wrong.

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

To clarify - such a "hot bed" could work like a "Zoo" or a place where
all these "trivial fixes" could "just be made" and then easily harvested
simply by using MC selective merging or something. Just a thought.

> Cheers,
>    - Andreas

regards, Göran