Vancouver meeting - clarifications
Hello, world,
please allow me as a member of the release team to share my view of the
issue as I have been invited to the vancouver meeting as well. The
contents of Steve's message were meant as a proposal, not as a definite
decision and of course any input from you, whether as maintainers, as
porters or as debian developers, is welcome. Personally however, I
didn't even remotely expect the outcome of this meeting to be what it
actually is. Otherwise, I would have discussed about that e.g. with
Wouter, whom I saw just before I left for Vancouver. I am sorry that
some of you had other impressions.
Please allow me another remark: That meeting didn't finalize the release
goals for etch. We talked about some of course - like we do on IRC quite
often, but we didn't finalize anything. The only settled difference to
sarge is that we need to move GFDLed docu out of main, but that's not our
decision, but the result of two GRs of all developers.
I was asked quite often via IRC what the reasonings for this kind of
proposal were. I'll answer the reasons from the release point of view - but
please remember that there are also ftp-masters/mirror concerns that the
release team doesn't directly take care of, but which are of course still
important.
As Steve wrote
| The reality is that keeping eleven
| architectures in a releasable state has been a major source of work for
| the release team, the d-i team, and the kernel team over the past year;
| not to mention the time spent by the DSA/buildd admins and the security
| team.
Considering the experience of the release team, the number of different
architectures were _one_ part responsible for release delays - not the only
one, and the others need also to be solved.
| - the release architecture must be publicly available to buy new
that has the reason that the system needs to be "alive". It can't be
Debians task to try to keep a dying arch up as long as possible. Of course,
there will be a timespan during which an arch is hard to buy, but still
useful and somehow available. We should of course support the release
during this time which would probably mean one or two releases but does
not mean we will be able to infintly support this arch.
| - the release architecture must have N+1 buildds where N is the number
| required to keep up with the volume of uploaded packages
The reason for this proposal should be instantly clear to everyone who
ever suffered from buildd backlogs. :)
We want that all unstable packages are directly built under normal
circumstances and that in the even of a buildd going down the arch does
not suffer noticably. The long periods of trying to get some RC-bugfix
in while some arch has a backlog should disappear with etch.
| - the release architecture must have successfully compiled 98% of the
| archive's source (excluding architecture-specific packages)
well, that's just an "the architecture is basically working", so that we
don't get too many RC-bugs because of architecture-specific issues, and
also don't get too many packages kept out of testing for not all archs
being built. Of course, the 98% is not engraved into stone, and might just
be another arbitrary high number like 97.5%. From looking at the usual
level where we start noticing problems with testing migrations, a number
in this range is sane.
| - the release architecture must have a working, tested installer
I hope that's obvious why. :)
| - the Security Team must be willing to provide long-term support for
| the architecture
If not, we can't release with that arch. I think this is also quite
obvious. Of course, one way to get the security team to provide support
might be to help them.
| - the Debian System Administrators (DSA) must be willing to support
| debian.org machine(s) of that architecture
| - there must be a developer-accessible debian.org machine for the
| architecture.
Well, the second point is - I hope - obvious why we want this. This first
one is just a conclusion of the second.
| - the Release Team can veto the architecture's inclusion if they have
| overwhelming concerns regarding the architecture's impact on the
| release quality or the release cycle length
This is just more or less an emergency-exit: If we consider an architecture
really unfit for release, we can use our veto. This is one of the things I
hope will never happen.
Something else which is related to the number of architectures in testing
is that we pay a price for every architecture:
For example, the more architectures are included the longer the migration
testing script takes. We are already at the limit currently (and also
have out-of-memory issues from time to time). For example, currently we
restrict the number of some hints to only 5 per day to keep up the
scripts. Also, the udebs are not taken into account, which requires more
manual intervention. With a lower number of release architecture, we can
and will improve our scripts.
Having said this, this all doesn't exclude the possibility for a
non-release arch to have some "testing" which can be (mostly) in sync with
the release architectures testing - just that if it breaks, the release
team is not forced anymore to hold the strings together. For example,
the amd64-people are doing something like that right now.
We are all committed to the quality of debian, and for faster releases, and
this proposal is one where we think we can help scale to more packages and
architectures, and still get the release time to an acceptable level.
I hope that this mail is able to shed some light onto these issues. Please
accept my apologies for the missing information in the first mail.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: