On Mon, Mar 14, 2005 at 03:32:40PM +0100, Jeroen van Wolffelaar wrote:
>
> Note that porter patches for kFreeBSD and amd64 so far seem, as far as I
> can see, to be relatively swiftly applied anyway by maintainers, despite
> those patches not being RC either. This suggests to me that also in the
> future with patches for SCC architectures, this should normally not be
> a problem, and of course, NMU's are possible otherwise.
Speaking as a patch-supplier for netbsd-i386 (Nienna), my experience has
been that many (even most) maintainers that are not simply asleep at
the wheel are willing to accept patches as long as they're fairly clear
in purpose and not too extensive. For most non-core packages, it can
be as simple as "need to grab a sanely recent autotools-dev", "please
re-libtoolize with <mumble> or higher", etc.
Core packages tend to make a lot more assumptions and be a lot less
portable, simply due to their nature (they tend to be meaningless on
non-Debian systems, which means frequently nobody has ever thought much
about a non-Linux, non-Glibc system). Even most of these are fairly
reasonable, though I've had a couple of flat refusals and a couple of
rather impressively long delays (no, I'm not going to name names, go look
it up in the BTS if you care).
I generally file FTBFS as 'wishlist' if it's a new package, and 'important'
if it previously built on the architecture and is now broken. It is fairly
rare for the latter to get downgraded, simply because it usually indicates
a fairly major issue that may apply elsewhere as well, and if a maintainer
is awake and friendly enough to porting that it has been built in the first
place, they tend to be willing to consider a regression to be important.
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature