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 <[EMAIL PROTECTED]> ,''`. : :' : `. `' `-
signature.asc
Description: Digital signature