Plan B for kfreebsd

[Steven Chamberlain <steven@pyro.eu.org>]

Jonathan Wiltshire wrote:
> We discussed kfreebsd at length, but are not satisfied that a
> release with Jessie will be of sufficient quality. We are dropping
> it as an official release architecture,

I hope we can come up with a suitable plan in response to this.

Here are some rather disorganised initial thoughts or ideas from me,
sorry about the ranting in places:

We managed to support kfreebsd-9 in wheezy with security updates,
which are fairly infrequent, even after the upstream support ended.
I think we could support the kfreebsd core packages for an unofficial
stable release, but we'd presumably need to build and distribute,
security and stable updates for the rest of the archive.  It's not
clear yet how much infrastructure we can keep or must replace.

AFAIK we had no concerns from DSA, or security team, and no serious
issues with our toolchains.  I believe d-i to be in good shape.

kfreebsd had zero RC bugs (or close to it) affecting jessie at the time
of freeze.  I'd say probably our core system is releasable already.

Glancing through the UDD bugs display, _most_ are not kernel or arch-
specific;  OTOH there are some bugs that probably _are_ Linux-specific;
looking at relevant packaging teams' dashboards I see:
  * 9+ RC bugs in Linux kernel packages (mostly initramfs-tools,
    mostly relating to use of systemd)
  * 3 RC bugs in systemd packages
  * 6+ RC bugs in GNOME packages (which we don't have any more on
    kfreebsd, and most are in network-manager)

Pessimistically I'd say the Debian GNU/Linux core system is in turmoil
from the systemd integration and the surrounding conflict, which has
had devastating consequences already.  I suspect the release won't
happen as planned, either the date will slip or the project will have
to endure painful organisational changes first.

So I'm keeping a very open mind to how we approach a kfreebsd release.

> [...] though we do hope that the
> porters will be able to make a simultaneous unofficial release.

I don't plan to throw in the towel due to this decision.  Many people
worked hard towards kfreebsd jessie:  many Debian teams have been
involved, users testing, maintainers handling bugs and patches,
upstreams and others helping to fix things.

We have something releaseable so we ought to release it, I think.
However I'm wondering first about what exactly is the purpose of a
release and whether we can do something that works even better for our
port.

Is it really necessary to wait for the official Debian release?
How long do we think we could support a stable release?  We could
even consider a longer or shorter lifecycle than official Debian.

We could commit to making the core system Long-Term Stable if we wanted,
or in the other direction, make it more like a rolling release by
bringing in things from sid/testing long before the official stable
release does.

If we handle stable updates, we could diverge from official policy:
we may be able to do a point release that updates to a newer upstream
kernel for example, if it's technically feasible.

I've also thought the freeze policy works awkwardly in some respects;
there are bugs affecting kfreebsd that I'd like to see fixed before
releasing, but probably wouldn't get a freeze exception.  If we produce
our own install media or have our own stable repositories, there may be
opportunities to make improvements this way.

On a vaguely similar topic, Steve Kemp had some good ideas about there
being "core" parts of the distribution, and whether the same release and
testing migration policies are really suitable for the rest of it:
http://blog.steve.org.uk/how_could_you_rationally_fork_debian_.html

And so I was reminded that another group of developers and users - those
still wanting to have Linux+sysvinit - may be rolling their own
unofficial install media for jessie too.

Whatever process/infrastructure we come up with, we should try to make
it inclusive for any other ports such as Hurd that may want to borrow
anything from it.  Conversely we can learn from them how they did an
unofficial release for wheezy.

Pre-built VM images would be a good idea.

A better recovery system than d-i would be nice to have for kfreebsd.

I even questioned before whether d-i in its current form is still the
ideal way to install a system, as public clouds often don't work that
way, and in case of Linux there is a fully-featured live system which
could launch a standalone install system.

And the very last thing to think about:  what to name/version it.  If
our release conincides with Debian's and is still quite integrated with
it, presumably Debian GNU/kFreeBSD jessie.  OTOH if we choose a
different release schedule, or must replace a lot of the processes and
infrastructure, it may seem more like a fork at a given point at time,
and we might call it something else.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org