Yup, that's exactly how it should work. With some exceptions of course
- if a major refactoring (like the toolbuilder stuff I integrated) is
overarching, an agreement can be made that one guy integrates
everything and the teams pick up the results. But usually, and I think
I proposed that, integrators work binary: either the package
integrates and is accepted, or it doesn't integrate and is rejected.

On 10/19/05, Hilaire Fernandes <hilaire at ext.cri74.org> wrote:
> Andreas Raab a écrit :
>
> > - Change the role of what is currently understood to be the "harvesters"
> > to something like a "release tester" group. The role of which group is
> > mostly to do integration testing by loading the packages from the
> > various maintainer's sites and test them. If there are issues the
> > release testers should report them back to the package maintainers and
> > work with them to fix these. Unilateral actions should only be taken if
> > a maintainer is unresponsible and there is real time pressure.
>
> Is not integration testing be something to be done by the package
> maintainers themeselves? (of course with the help of the release tester
> group as you definied it).
> This could help to keep low the overheating, in particular when
> maintainers are not interested/can not help for integration.
>
> If a maintainers is not interested/can not work for the integration, the
> package could just be dropped. Just the usual process of free software:
> evolve or die.
>
> If you look at how it works for the Gnome or KDE applications, with each
> new major Gnome and KDE release, the applications developpers must
> updated their own code to get it work with the new desktop release (and
> I know about that).
> It is not a task the core developers of Gnome and KDE can do.
>
> Hilaire Fernandes
>
>
>