Haines Brown wrote:
> Instead of waiting for some messages to ascertain the culture of this
> list, I'm so excited to hear of a fork that I boldly jump in with a
> question.
>
> I would like to have a clarification of the difference between a
> preseeded installation of Debian and a fork of Debian. I'd guess the
> former simply manipulates a Debian installation, while the latter is a
> different distribution that rather than preseed involves different
> compatible default packages. Is the Devuan Project starting with a
> built-in preseed and working toward a forked distribution by Spring
> 2015?
>

This is loosely based on something I posted to the modular-debian list -
the other place where folks are actively discussing a fork
(https://www.freelists.org/post/modular-debian/Goals-and-Starting-points).
That list is described as "discuss(ing) ways to maintain a more modular
Debian ecosystem, and to avoid snowballing dependencies on a single init
system" - but seems to have become focused more generally on ways
forward for those unsatisfied with Debian's direction.


1. What are the GOALS of the Devuan fork?

From the "Don't Panic and Fork Debian" post that announced Devuan:

"Devuan aims to be a base distribution whose mission is to put the
freedom of users: to be intended as developers, sysadmins and in
general tech-savvy people, as the majority of Debian users are. Among
the priorities are: enable diversity, interoperability and backward
compatibility for the existing Debian downstream willing to preserve
Init Freedom and avoid the opaque and homogenizing systemd avalanche."

That's just a bit vague. Seems to me that we need a bit more
specificity as to the focus and nature of the fork - such as:
- Complete fork vs. a derivative
- Desktop focused vs. Server focused (personally, servers are a lot more
important)

And, with the project defined as a "Debian fork," it would do us well
to ask "what makes Debian, Debian" and what of those characteristics
establish critical technical and project goals. My list, so far:
"what is it about Debian that makes it 'Debian' and what do we want to
keep?" At a minimum, it strikes me that Debian is defined by:
- it's packaging system - dpkg & apt (to me, without apt, it isn't Debian)
- it's installer
- the compendium of upstream code that's been packaged and resides in
the Debian repo
- arguably, Debian policy (technical architecture, really) - on the
modular-debian list, someone made a pretty compelling argument that
Debian policy is what holds the distro together -- one might suggest
that changes to Debian policy, regarding "diversity, interoperability
and backward compatibility" (and I'd add, sticking to the "Unix way")
would be a good jumping off point for Devuan

2. What's the STRATEGY for achieving those goals?

Outside of a true fork, other options present themselves (with relaxed
goals):
- Wait-and-see: It could be that Jessie will be Debian's equivalent of
Microsoft Vista - with sanity returning in Jessie+1. Meanwhile focus on
LTS for Wheezy (think Windows XP), and maybe playing some
techno-politics to influence future directions. Unfortunately, I have
the sinking feeling that this ship has sailed - for Debian, maybe for
much of Linux.
- Other distros: Gentoo and Funtoo, obviously, and the resurgence of
work on GNU Linux looks promising (GUIX's approach to build-to-order
packaging is awfully compelling).
- Other platforms entirely (I've been keeping my eye on SmartOS, and on
work with exokernels and unikernals - Erlang-on-Xen is looking awfully
nice for some of our upcoming development work)

But for an explicit "Debian Fork" that question becomes: Where to
start, what to build on, what has to be done new, by whom, and how?

The "Don't Panic and Fork Debian" message lays out some of this:

- "Devuan will derive its own installer and package repositories from
Debian, modifying them where necessary, with the first goal of
removing systemd, still inheriting the Debian development workflow and
continuing it on a different path: free from bloat as a minimalist
base distro should be. Users will be able to switch from Debian 7 to
Devuan smoothly, as if they would dist-upgrade to Jessie."

- Devuan will make an effort to rebuild an infrastructure similar to
Debian, but will also take the opportunity to innovate some of its
practices.

Which does suggest that we might consider collaboration with other folks
who are engaged in similar activities, notably:

- the Debian GNU/kFreeBSD folks are actively trying to figure out who to
keep going, now that the release team has dropped them from the Jessie
release
- the Dyson project (illumos with a Debian userland)

Somehow, it seems like common infrastructure would save a lot of work.

And then there's the question of organization:

- Debian has clearly become way to baroque in its organization, decision
making, and "techno-politics" -- that's how we got here
- the "Don't Panic and Fork Debian" message includes: "Devuan developers
look at this project as a fresh new start
for a community of interested people and do not intend to enforce the
vexation of hierarchy and bureaucracy that is often opposing
innovation in Debian. We are well conscious this is possible mostly
because of starting small again and we will do our best to not repeat
the same mistakes."

Which leads to the central questions of "who" and at least general
principles of how work will be organized and decisions made (as has come
up in the discussion of anonymity).

Traditionally, a successful model has been that of an individual or
small group driving the project, at least in its early years.
"Benevolent dictatorship" has been somewhat more successful than
management by committee. Examples that come to mind immediately
include: the small Bell Labs team that brought us Unix, Bill Joy
(Solaris), Linus Torvolds and the kernel (obviously), Ian Murdock and
Debian (with initial support from the FSF, which brings Richard Stallman
to mind), and Daniel Robbins (Enoch Linux, which begat Gentoo, which
begat Funtoo).

I'm not actually sure I can think of a good example of an o/s developed
by committee (maybe IBM System/360).

Which does bring me back to the core questions of:
- who is actually driving Devuan, what are their (your) personal goals
for the system, what design philosophies and track record are they (you)
bringing to the table, and, based on that,
- how are the efforts of others to be incorporated into the effort?
(Note: With the right people, I'm fine with strong technical and project
leadership, and benevolent dictatorship. With the wrong people at the
helm, I run in the other direction.)

Respectfully,

Miles Fidelman








--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra