Adam Borowski wrote:
> John Paul Adrian Glaubitz wrote:
> > > We have a testing distribution in debian-ports?
>
> We don't, which is a shame. This badly hinders stuff like porting d-i
> [...]
Without those things, many will struggle to install the port or
do much development on it. Some options are:
1. snapshot sid during the freeze, patch some packages and build
install media mostly by hand - I think hurd releases are done
something like this;
2. debian-ports.org having one or more Britney instances that produce
'testing' suites - rolling releases basically;
3. or make it easier somehow for ports to become release arches?
where I think the latter, stable releases, are mandatory to ever have
DSA-administered buildds, which in turn is a requirement for getting
into the official release.
> But it appears like Steven meant official release archs.
Yes. I was thinking of https://bugs.debian.org/815885
(FTBFS on mips was blocking security fixes from migrating)
That was quite easily fixed by the porters, but it could have been
handled much better I think:
* porters are typically not notified, unless someone files a FTBFS bug
and copies the appropriate mailing list - sometimes it never happens
at all;
* it seems a patch was sent but wasn't attached to any BTS bug so it
got lost and not applied earlier;
* *if* the bug stayed unfixed for weeks, delaying fixes from migrating
to testing, that's will annoy maintainers. If no porters fixed this
bug, isn't it fair that doko could remove the out-of-date binaries
on that arch? (Essentially leaving it without Java unless fixed).
For example, with kfreebsd it got too difficult to port many GNOME3
packages. Removing GNOME3 and dependencies from kfreebsd took huge
pressure off maintainers and porters; everyone was able to concentrate
on other things that really mattered - making GNOME3 better on linux;
and defaulting kfreebsd to another desktop that simply worked, so
porters could spend time on other things.
I saw another example of an arm64 FTBFS keeping a video driver for
MIPS systems out of testing. An arch-specific removal is obviously
the right thing to do there.
> it would practically mean declaring everything but i386/amd64
> unimportant
I don't want that outcome, I value the ports very highly. (OTOH
some might even say i386 is unimportant now...)
I want the opposite, making ports more convenient to have in the
official releases, so we can actually have more of them. Perhaps
slimming them down to something really small (perhaps some not having
Java, or even no X11). It is nice to be able to release *something*
from the official archive that is installable, stable and you can build
other packages on. You can easily enough put a testing/sid chroot on
that system to install things that get ported later.
> it doesn't force you to port new stuff but requires a manual action
> (filing an arch-specific RM) to allow regressions.
I hope porters get notified first, and a chance to fix the issue. A
FTBFS bug that gets no answer is supporting evidence for removal.
Filing those things can be tedious (which is why it often stays
unhandled for so long) so I like the idea of it being somewhat
automated.
Recently, Andreas Beckmann filed dozens of FTBFS-on-kfreebsd bugs.
Once I had them in my mailbox, it was really easy for me to reply to
each one, and I even attached a patch for more than half. The effort
of filing the bug had actually put me off working on them.
In other cases the package really did want de-crufting; if kfreebsd was
still in testing, we'd have needlessly held up those from migrating.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature