Re: Release Team Meeting results (the Juelich Edition)
Andreas Barth a écrit :
> Hi,
Hi!
[snip]
> * Quality Assurance (QA) checks on the archive were started very late in
> the cycle. They were very useful, but the timing was very unfortunate.
> We want to encourage all interested parties to start their QA checks as
> early as possible and will try to support those by making them a release
> goal. Regular rebuilds, upgrade tests for standard configurations and
> similiar checks improve Debian's quality!
IMHO if you want the QA to be done early in the release cycle, you will
have to freeze the policy really soon. Any change to the policy can
potentially create hundreds on RC bug.
The first step is probably to get debian-policy team back to life, and
process all the pending issues.
[snip]
> Architecture (re)qualification
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> We will basically continue to use the same criteria for architecture
> qualification that were in use for Etch. Some small changes include that we
> really want to send out the architecture status at least every second
> month. Of course, we need to recheck the criteria soon - but that's left
> for a later occasion. Two new criteria were split of the existing criteria:
> We split "RM concerns" into "RM concerns" and "SRM concerns", and we split
> of from "buildd redundancy" "fast security buildds". Nothing too exciting
> anyway.
>
> We also discussed some specific archs:
>
> * As far as we understood, arm is going to die soon, being replaced by
> armeb and/or armel. We would like to hear some comments from the porters
> about this before deciding if arm should even still be released with
> Lenny. If it is really going to die soonish, but is still in regular
> use, one option would be to release it with Lenny, but without a
> debian-installer, so that new installations are forced to the newer
> armeb, and purge arm after release of Lenny. But that is just a
> proposal to start off the discussion.
The eventual goal is to get *armel* replacing arm. armeb is a different
effort, but I am not sure it is still really live (at least by judging
of the graphs on buildd.net).
At debconf, there will be a talk from Wookey presenting the armel port.
Later in the week a bof is scheduled to discuss the issues about the arm
ports. I really invite at least one of the releases managers to come.
> * kfreebsd-{i386,amd64} has seen some improvement in the last year and
> looks like it could be ready in time for Lenny. As with the other
> architectures, we would like some statements from the porters to better
> understand which of the release criteria could still be a problem.
I prefer to discuss with the other porters before commenting that. We
will issue a statement in a specific mail in the next few days.
> As we understand that archive and release qualification is often a problem,
> Andi, Martin and Marc (HE) want to provide a new service:
>
> doorstep.debian.net will be installed on a machine in the next few weeks
> and will provide a normal dak installation and a wanna-build database, so
> that packages can be autobuilt. Source packages will be kept in sync with
> the main archive. We will also set up britney instance to allow for a
> testing suite in that archive. This service is intended to be used as a
> test environment so that architectures can show their maturity before being
> added to ftp.debian.org.
>
Both armel and kfreebsd-* are currently hosted on ftp.gnuab.org, have a
wanna-build database and some build daemons. The only difference I see
in your proposal with doorstep.debian.net is the possibility to have a
testing suite. But this is a huge benefit.
On the other side we will loose the unreleased suite that we use to put
patched packages, until package maintainers actually apply the patches
sent to the BTS in their packages. And that can take months or years. We
should really discuss with the release team a policy about NMUing
packages for non-official architectures that are candidate for
ftp.debian.org.
I am however worried by the way to switch from one archive to another.
If it implies one more rebuild of the archive, I am not sure it is worth
doing the switch.
Rebuilding an archive takes a lot of time and is really painfull.
Machine time for sure, but also human time. It means carrying about the
build daemons a lot more than in normal time, bootstrapping a lot of
packages that have mutual build-dependency. Also the most problematic
thing is key packages in the build tree that are not buildable in
unstable, sometimes for days or week (as an example, most packages
depending on libflac-dev are currently unbuildable in unstable).
Sometimes you have no other way than waiting...
One solution is to find a way to directly import either gnuab.org into
doorstep.debian.net or later doorstep.debian.net into ftp.debian.org. Or
even both. This is even more critical for armel, as we have started a
full rebuild of the archive in a clean way about two months ago. I don't
think Riku Voipio would really appreciate if you tell him that all his
efforts in the last two months are lost...
Riku and I will be at Debconf, I really think we should meet with the
release team to discuss about the archive issues for armel,
kfreebsd-i386 and kfreebsd-amd64.
Cheers,
Aurelien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: