Re: Vancouver meeting - clarifications
On Tue, 15 Mar 2005 08:58:44 +0100, Andreas Barth
<aba@not.so.argh.org> wrote:
>Hello, world,
Hello, Andi.
Nice to hear from you.
>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.
Good. Please take note that the finanlizing needs to be done in a
different process.
>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.
However, I currently do not expect ftpmaster to communicate with mere
mortals, so their motivation will probably remain in the dark as many
other parts of their mysterious day-to-day-work we all happen to
heavily depend on.
>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.
Can you outline the delays that were caused by the number of different
architectures?
>| - 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.
Why? We have been filling that gap nicely, providing for a solid user
base. This has also been a promotion for mainstream architectures, and
a motivation to keep a Debian system reasonably small. I can imagine
that a lot of people decided to use Debian on their currently
productive systems because the same system also runs on the nice gem
in the basement. You guys are suggesting throwing that away.
> 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.
Infinity is of course not an option.
>| - 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.
I am missing the rationale for the upper bound on number of buildds.
>| - 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.
It needs, however, to be more tightly specified how that number is
determined. Will an architecture be dropped if it drops below for one
day? Or is it needed to constantly stay below that threshold for the
entire release period?
>| - the release architecture must have a working, tested installer
>I hope that's obvious why. :)
The architectures you plan to release have a working installer,
anaconda, for years. d-i was developed to allow release of all
architectures. You are dropping that requirement, flushing all d-i
efforts down the drain.
>| - 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.
I do not recall the security team requesting help for supporting other
architectures than i386. otoh, other teams of debian have a history of
rejecting help offers. That makes the mere mortal developer reluctant
with offering help to teams any more since nobody likes rejection.
>| - 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.
This allows the DSA to veto out any architecture.
>| - 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.
It, however, allows the release team to veto out any architecture.
>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.
But why are you precluding that architectures do their own testing?
>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
Well, it does. The only official support that your paper still offers
to non-release architectures is the possibility to have snapshots of
unstable. Yes, they're free to do their own testing on their own
infrastructure, but pulling our infrastructure from them is "dropping
the architecture".
>- just that if it breaks, the release
>team is not forced anymore to hold the strings together.
That is OK, IMO.
>For example,
>the amd64-people are doing something like that right now.
They are causing a sizeable burden for alioth.
>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.
You are not scaling for more architectures, you are throwing things
out, committing them to a peaceful death so that they can be
unceremoniously removed.
>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.
I am still deeply disappointed.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: