On Wed, Mar 07, 2007 at 12:34:44AM -0600, Drew Scott Daniels wrote:
> Porting Debian to a non-Linux kernel. kFreeBSD opens the doors for knetbsd,
> Some highlights from there include devfs, OSS, OpenBSD Packet Filter
> (pf), jails, Xbox port, better in several benchmarks...

Does the Debian kFreeBSD work on XBox? What benchmarks, and does the
GNU userspace change that result?

> > 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.

Ooo. Neat.

> 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?

> Real Concerns?
> --------------
> I feel your concern is likely, why add kfreebsd/i386, kfreebsd/amd64,
> knetbsd/alpha... and so many other to the archive. 

That's not so much the case anymore.

> It [...] makes release management more difficult, 

And that's a concern for the release team and the release criteria,
not inclusion in the archive.

> 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.)

> I've gathered knowledge from official logged IRC meetings (which I 
> attended), 

URL?

> 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).

The plan hasn't; we'll be creating an "m68k-etch" suite that the m68k
crew can maintain similarly to the sarge amd64 release, except remaining
on ftp-master. If m68k requalifies for lenny, that'll be about the extent
of it.

> Perhaps you could help get a clear plan for kfreebsd's port
> status (scc, archive, patches...).

I'd suggest the kfreebsd porters do this, and expect to fill in details
or rearrange steps when they encounter any problems. If it were me,
I'd go for something like:

        GOAL: have Debian support lots of different OSes

        1. Support lots of Linux ports.
                a. Mostly done!
                b. Get m68k back, though?
                c. arm and m68k binfmt changes?
                d. sh or others?
        2. Get some other very similar OSes official
                a. kfreebsd -- easy!
                        i.   add it to the archive!
                                - straight after etch release?
                                - promote ging livecd?
                                - do a vmware-format image?
                                - update archive qualification page?
                        ii.  intro and demos at debconf?
                        iii. developer accessible machines?
                        iv.  kfreebsd strike force?
                        v.   piuparts or other automated testing infrastructure?
                        vi.  release consideration?
                        vii. installation methods?
                b. integrate support for embedded systems, debonaras etc
                c. GNU/Solaris -- political issues though
        3. Get some more interesting OSes ported/released
                a. Hurd?
                b. ReactOS?
                c. MacOS userspace?
                d. Windows userspace?
                e. Minix 3?
                f. Plan9?

...and see who wants to sign up to help with the different parts and
flesh bits out, and if there are any other ways to exceed expectations
on each of the various points. But I don't know if that /is/ the goal
you're going for overall, or if it's something different.

Cheers,
aj

Attachment: signature.asc
Description: Digital signature

Reply via email to