It seems the largest problem to including kfreebsd into the archive or as an official Debian port is communications. There may be technical or social reasons too, but they're sometimes difficult to identify without enough communication.
On Tue, 6 Mar 2007 13:58:42 +1000, Anthony Towns wrote: > On Mon, Mar 05, 2007 at 06:18:56PM -0800, Russ Allbery wrote: > > Anthony Towns <aj@azure.humbug.org.au> writes: > > > I'd love to be proved wrong on kfreebsd's value to users and the > > > project. [...] > If kfreebsd gets added to Debian, I'm going to get asked "So, kfreebsd, > huh?" and I'd love to be able to respond in a really positive way: > "yes, it solves ____ a problem" or "it demonstrates this really awesome > new technique, _____, that's miles beyond anything else, even linux" > or /something/. [...] Porting Debian to a non-Linux kernel. kFreeBSD opens the doors for knetbsd, kopenbsd, kdragonflybsd. They all have quite a few similarities. http://wiki.debian.org/ArchiveQualification/kfreebsd-i386 and http://wiki.debian.org/Debian_GNU/kFreeBSDGNU/kFreeBSD_why list other reasons. If the reasons are still not sufficient (they weren't as you noted), please note in more detail. Some highlights from there include devfs, OSS, OpenBSD Packet Filter (pf), jails, Xbox port, better in several benchmarks... Making Debian work on another kernel makes it easier to do other porting work. The kfreebsd port has helped the HURD and even 68k ports (e.g. see some of the glibc TLS related work). Making more ports helps make packages more portable to new unofficial, or even new official ports. [...] > One thing I'd like to see for candidate x86/x86_64 architectures is a > preinstalled vmware-format image (which aiui will work under both qemu > and vmplayer) that can be used to easily demonstrate what's so fantastic > about a new OS. [...] Is GING not enough? This is the first I've heard of this particular request. I think it could be accommodated. [...] > Given something fantastic that makes it all worthwhile, all the > practical > things can be solved. Without any particularly interesting goals that > get people excited and involved and can be clearly described, I think > there'll be long term problems in keeping the port active. [...] The motivation to work on this in the future includes many of the same motivations as HURD on L4 and all the BSD distributions. I can't say I totally understand especially given that "netbsd is dying" and other related problems, but then I can't say I totally understand the motivation for Debian. >From a point of view of users, many ISPs run FreeBSD and people like the GNU utilities that Debian provides (I install GNU utilities on AIX, Solaris and Windows). Netcraft has an interesting list at http://uptime.netcraft.com/perf/reports/performance/Hosters?tn=february_2007 I also recently read that WindRiver beleive(d) many embedded customers would prefer BSD over Linux. Some others might find motivation in the differences between GPLv2 and BSD. For me the motivation is mostly "because I can", I've got old hardware I want knetbsd on, and because kfreebsd really helps improve portability to other platforms that I'm interested in working on (perhaps only for unofficial usage). I'd like to see Debian help make software more portable. Real Concerns? -------------- I feel your concern is likely, why add kfreebsd/i386, kfreebsd/amd64, knetbsd/alpha... and so many other to the archive. It creates ftp master work, takes up Debian resources, makes release management more difficult, makes security work more difficult... I'd argue that kfreebsd/i386 is in far better shape than the rest. kfreebsd/amd64 isn't far behind, but the motivation for the other BSDs doesn't seem to yet be high enough. Another port, win32 is likely far away. Personally I've been bothered by the hostility towards such a port by glibc, gcc etc. Not specifically the port, but the high amount of work seemingly demanded to work with upstream. FreeBSD helps with some of that through their ports collection (although a few kfreebsd developers have done quite a bit for glibc on their ports). ReactOS at FOSDEM seemed to understate their current status. ReactOS can be used to host compiling ReactOS, and can run many applications and drivers. Stability still may need some work, and the politics there are a bit different. ksolaris may happen some day if the politics get sorted out, but with the current group dismissing GPLv3 in the manor they did, it seems they would be quite hostile towards debian-legal. Perhaps that's a good DPL opportunity for negotiation. 68k seems to have elected to skip official etch, but also seems to have met the requirements. Some of the non-dd porters still want an official etch release. A port to uclibc seems to be content to have some packages in the archive. I think this makes sense as porters will likely have to recompile most things for their platform. Some buildd time might be nice to help maintain compatibility. Most other distributions don't have as much as Debian for this it seems. Some analogies are why add another package, another library, kde vs gnome... Perhaps these analogies are too weak, but are worth considering. I feel the real concerns for kfreebsd porters are in getting patches accepted, and having some additional resources. For now this may be accomplished outside the Debian resources, but official recognition might make things more easy, both in Debian, and upstream. It may even encourage more developers. I've gathered knowledge from official logged IRC meetings (which I attended), quite a few mailing list messages, and a few web pages (some linked here). I hope I got the concerns correct. Future agreements/plans? ------------------------ aj, I like how you got a clear concise agreement from the 68k porters a few months ago on debian-release (although I think the situation has changed). Perhaps you could help get a clear plan for kfreebsd's port status (scc, archive, patches...). Also, I think we need to collect information from the Security Team, the Release Team, the ftp masters, debian-admin, debian-boot and any other group that may have additional work (although perhaps minor) or who will need additional resources. Thanks, Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]