Bits from the Release Team: Architecture health check
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
* Architecture health check
* "Recursive" auto-removals temporarily suspended
* Auto-removals now listed on the PTS
Architecture health check
=========================
During an IRC-meeting on the 26th of January, the Release Team
reviewed the status of the architectures in sid.
The following architectures are currently doing well enough to be
release architectures:
* amd64
* i386
* powerpc
- The architecture has improved since we warned it.
* s390x
The following architectures are not doing well enough to be considered
release architectures:
* hurd-i386
- The architecture is not in testing, which is status quo.
* ia64
- We have seen no improvements and intend to remove it from
testing.
* sparc
- We have seen no improvements. Therefore, out of date
binaries on sparc will no longer prevent packages from
migrating to testing and Britney will be allowed to break
existing packages in testing on sparc.
- We will review sparc again in about 2 months; should porters
have stepped up and resolved the concerns we had about sparc
we will consider undoing this change. Otherwise, we will
remove sparc from testing as well.
This leaves 6 architectures:
* armel and armhf
- We are mostly happy, but we are a bit concerned that the
architectures (especially armhf) might be a bit short on
buildd redundancy (buildspeed-wise). Héctor Orón has
promised to do an assessment on the situation and we now
await his results.
- armel and armhf remain in testing as candidate release
architectures for now.
* mips and mipsel
- On the 17th of January, the mips and mipsel porters
approached DSA and the Release Team with a proposal for
resolving our concerns with hardware issues for these ports.
The proposal looks promising and we have decided to defer
the decision regarding these architectures for now.
- mips and mipsel remain in testing as candidate release
architectures for now.
* kfreebsd-amd64 and kfreebsd-i386
- On one hand, we are unconvinced that kFreeBSD will be able
to be on par with other release architectures in terms of
supported packages for Jessie.
- On the other hand, we believe kFreeBSD could be improved by
reducing the scope of the port for Jessie.
- Therefore, we would like to invite the kFreeBSD porters to a
dialogue to determine the scope of kFreeBSD for Jessie. If
we can come to a agreement on this and both sides can live
up to the agreement, kFreeBSD will become a release
architecture for Jessie.
- kfreebsd-amd64 and kfreebsd-i386 remain in testing as
candidate release architectures for now.
We intend to review *all* architectures once again in about 2 months
from now.
Mini-FAQ:
Q: Why does kFreeBSD get the offer to reduce its scope, while
Hurd did not?
A: We believe the kFreeBSD ports to be sufficiently close to a
release architecture in terms of supported packages for a scope
reduction to make sense. At this time, we do not feel we can
say the same for Hurd.
Q: What were the problems with sparc again?
A: Kernel in stable does not work and sparc is still using gcc-4.6
as default compiler.
"Recursive" auto-removals temporarily suspended
===============================================
We have received complaints that package maintainers felt surprised
and inadequately warned, when their packages were removed due to a(n
indirect) dependency being removed. Therefore, we have decided to
temporarily suspend removals of packages that have reverse
dependencies until a "push-notification" is in place.
As soon as this issue is resolved, we will re-enable recursive
automatic removals.
This issue is currently tracked as #734396.
Auto-removals now listed on the PTS
===================================
Thanks to the work of Ivo De Decker and Paul Wise, the PTS will now
display a warning for packages that are about to be auto-removed from
testing.
Niels, on behalf of the Release Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJS6UrqAAoJEAVLu599gGRCaX8P/jJHjfvEhtmVlt7bbD77dNOW
5omS0uEfLWCwJRAS0KadjEiyGSsTAacJENUAuYlL3N8e856dJ9HQhf3Aiq1OpYIx
9l2FZgAsNsIL8q+UFkRe0OGUE/yBBar3tSRDkAbUd7t+m3m5Ij8mzo4yN/Qm90SV
pF3PFY+rUyBY2DfVQlu0p5QWd6SocYi7z2NsZbQnaqBuu/nsleE0VQGBYQ2JfXBZ
v31q49NbTE3u30Zn5UGnJPaayRcWwVqD8fHVrS3iEGO2hnmNbWfGDqhxi0iS0L48
M+B4ql5XbH6PEFucjmdXjcnKJo5FyMjyqgtOCFdVs+kKImosTMAQUP0MNHUhLGlf
ODXPggNzKBelz6q1tPNQFkHj5CbbW0pv8AJm/pJ2sXrishn/ulU0k2dHm0TKiYL+
MpWDSvTONl7ySTy3GeKXPKDs9zipKF7pAXLBG+YYwGkg0vEaD5T0qtXCmeeEnTW0
xzdU1qGWQFEJzqmERfnEXNGfBDbB26peW0xBu5+vwJSFbYqAduCvWWbzqrk8EfbL
/vvRP9pj9HPjlc8SL4RQDP3oObtLmcM5AUS/1Drxqf8vDzebyeaZQ98m4uovn/nF
FRscLBxNGztRAs9WVvQ5X3ltVWAcGdBp6/TiTLSPF1D9NvetqbZo5HOSeBLTzEDD
cTG7do0gxzB4cYmqqbxL
=WmfC
-----END PGP SIGNATURE-----
Reply to: