How to show $arch releaseability (was: Re: How to define a release architecture)
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.
As Steve mentioned in another mail[1], one of the points where arches offload
work onto the release team is
"3) chasing down, or just waiting on (which means, taking time to poll the
package's status to find out why a bug tagged 'testing' is still open),
missing builds or fixes for build failures on individual architectures that
are blocking RC bugfixes from reaching testing"
This is something I believe porters should be able to do on their own. Without
delegation from the DPL, blessing via a GR or any other procedural
smoke-screen. As long as people interested in an arch don't pay someone for
it and they don't find someone else who does it for it currently looks to me
that they will have to do it themselves, since the current release team is no
longer willing to do it for them.
I already hear people complaining "but until now they did it, why do they
suddenly stop it now??". To which I can only answer that we are talking about
etch which we want to release in two years time, that are two years anyone
who is interested can demonstrate that he (or she) is commited and capable
that the arch in question is a viable candidate for testing/stable proper.
How could this be shown?
1) One could hack britney that it mirrors REGULAR testing and additionally
moves packages from $arch iff they are fit, or removes the package from your
local testing iff propagating it in REGULAR testing would get the arch out of
sync. With this one has a good measure of how good ones arch is keeping up
with testing.
2) Trying to get/keep ones local testing repository up to speed leads directly
to the problems, the release team had (has) to solve for sarge.
3) This problems can be solved by quick autobuilding, working with
maintainers, porter-NMUs and so on.
4) Finally one can publically demonstrate (by showing the working local
repository) that one is committed and capable of running testing for $arch.
Regards, David
[1] http://lists.debian.org/debian-devel/2005/03/msg02334.html
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Reply to: