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
