[Proposal] $arch release assistants
Hello Debian-developer,
I have a modest proposal to reduce the burden of the multiple
architectures on the Release team. This is based on the following
assumptions:
I) The main problem is missing builds that slow down propagation to
testing.
II) Such problems are linked to buildd breakages that can happen at
random time.
The idea is to have or each architecture $arch a '$arch release assistant'
which is in charge of helping the release team with issue specific to a
port. As I see it:
1) The $arch release assistant is not a buildd admin.
2) The $arch release assistant is trusted by the buildd admin and
ftp-masters for the purpose of making binary upload (See [1] why it is
important).
3) The $arch release assistant monitor debian-release to detect when
missing $arch builds are needed to propagate fix for RC bug to testing.
When this happen (normally because of buildd outage) they fast-track the
package (e.g. by building the package on their box) to make the transition
faster.
4) Preferably, they can manage a buildd when the buildd admin is in
holiday, but this is not needed from the start.
5) The $arch release assistant helps the release team dealing with
architecture specific issues in upgrades (e.g kernel upgrade needed
before a woody-to-sarge upgrade on some platform).
The issues to address for this scheme to work:
A) The point (2) needs a protocol for building binary outside official
buildds that is approved by the ftp-masters.
B) There is a trust to establish between buildd admin/ftp-masters/release team
and the $arch release assistant.
C) Volunteers are needed.
I thing A) and B) can be solved with a bit of good-will from all part.
C) should not be a problem unless the port is dead. The difficulty is
to have C) and B) at the same time. I hope we are reasonable people.
Cheers,
--
Bill. <ballombe@debian.org>
[1] http://lists.debian.org/debian-ctte/2004/12/msg00001.html
(Apologies to Blars).
Imagine a large red swirl here.
Reply to: