Getting patches applied. emulated buildd's are good (was: kFreeBSD is "fantastic")
guillem's  list of bugs  shows the main problem for the kfreebsd
porters. 93 "important" (probably release-critical for kfreebsd) with
patches available! 105 bugs with patches not applied. Certainly getting
in the archive would give them more time though.
Should porters be required to NMU? I would hope not in this quantity as
someone who NMU's should consider themselves a virtual maintainer until
the next upload (or at least I've read this a few times from people such
Simply having etch released is not sufficient motivation for some
maintainers. See the age of some of the bugs.
Perhaps another candidate might also help solve this wider social
Perhaps we can recommend marking bugs as -patch if the patch is no good?
Maybe a user tag or some way of having patches marked as needing more
review? I think if we did these, we'd still see that good patches aren't
being applied but at least we'd be able to help more quickly identify
where work is needed.
I'm guessing it's due to lack of time for developers which may mean
they should be getting a co-maintainer? We may also find
the pool of co-maintainers to be low (some packages have).
On Thu, 8 Mar 2007 17:40:21 +1000, Anthony Towns wrote:
> Does the Debian kFreeBSD work on XBox? What benchmarks, and does the
> GNU userspace change that result?
"Some people say that kFreeBSD has better performance and/or stability
(especially in disk/filesystem areas)." 
"http://bulk.fefe.de/scalability/ has a list of benchmarks that compare
kFreeBSD 5 with Linux 2.6. The benchmarks claim that kFreeBSD performs
better than Linux on network connections under high load (~4000 open
> > For me the motivation is [...]
> > and because kfreebsd really helps improve portability to
> > other platforms that I'm interested in working on
> How so? Do you mean m68k in this case, or platforms kfreebsd supports
> but i386 (Linux) doesn't?
One such target is a netbsd sub-architecture that the Linux maintainer
rejected. The bus is actually now implemented on Linux target, but not
with the CPU I want.
kfreebsd has helped packages port to HURD, m68k, mipsel ... Many
problems are simply build configurations that are unnecessarily
> > It [...] makes release management more difficult,
> And that's a concern for the release team and the release criteria,
> not inclusion in the archive.
Good to know, but it would be good to have their opinions in order to
help improve the port. Even having them point out obvious problems helps
communications. I attempted to get some feedback , but I guess it's a busy
> > 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.
> (They met the requirements after the architecture freeze, and only using
> emulated buildds, which needs some more discussion before being suitable
> for release.)
This should be discussed then. The consensus I've been reading on
debian-68k is that emulated buildds produce better code than real
hardware. Can you help lead or find someone to lead this discussion? Perhaps
a poll or irc meeting might help.
> > I've gathered knowledge from official logged IRC meetings (which I
> > attended),
I was avoiding the time looking it up, but:
Google also shows me some other interesting kfreebsd irc meeting logs.
Pierre Habouzit answered the rest  pretty well. See also that debian-bsd
also answers user questions promptly from time to time.
<20070307103954.GA16359@zulo.hadrons.org> Guillem Jover, viewed 20070308
 <http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;firstname.lastname@example.org> Various, viewed 20070308
 <http://wiki.debian.org/ArchiveQualification/kfreebsd-i386> Various,
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408076 Petr Salinger
et. al., viewed 20070308
<20070214072036.GC11307@zimmer>, Drew Daniels, viewed 20070308
<20070308111106.GB17572@mad.intersec.eu> Pierre Habouzit, viewed