Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 11:02:47AM +0100, David Schmitt wrote:
> On Tuesday 22 March 2005 08:22, Sven Luther wrote:
> > On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote:
> > > > No. There needs to be some override procedure like we have for
> > > > maintainers not doing their job. But that's beyond the scope of this
> > > > discussion.
> > >
> > > In this case, there is nothing to override, because the overrides are
> > > actually changing something in the teams so that the team changes their
> > > mind (that might actually mean there is nobody who opposed the change in
> > > the team anymore, in a worst-case scenario).
> > >
> > > So, this should not be a point of contention in this sphere at all. It
> > > belongs in some other level. Let's drop this point as a contention
> > > point, then?
> >
> > No, this is the main problem, that there is no counter power or limitation
> > to what they can decide. We saw this already in the amd64 GR issue, and we
> > can either accept their decission or have them resign in masse and be
> > prepared to replace them.
> >
> > There is no accountability, and altough the DPL supposedly mandated them,
> > he has no actual power to do anything about it.
>
> If (for whatever reasons) none of the people behind the "release team" is
> willing to work on an arch, there is nothing anybody can do to "force" them
> to. Not tech-ctte, not the DPL, no GR, nothing! Yes, they can (and if they
> become crazy in the head they probably should) be removed from their position
> then but this doesn't magically do the work needed for a release.
The problem is when they actively oppose work.
Sven Luther
Reply to: