systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Bill Nottingham]

Matthew Miller (mattdm at mattdm.org) said: 
> > The intent is not to do so in the final release, AIUI. We're only
> > keeping it around during pre-release, so that if we decide we need to
> > fall back to upstart for final release, it's easy to do. As far as I
> > know, the plan is to decide later (presumably after beta) which one
> > we're going with, and dump the other.
> 
> Making a big change like that _after_ beta seems like an invitation to
> trouble, but I'll give the benefit of the doubt to you as the QA guy. So in
> that case, the requirement could simply be that at the time of the beta,
> they do basically the same things, or in cases where they do different
> things, it is 1) intentional *and* 2) documented.

My concern is with maintaining two init systems for the life of the release.
We have two potential situations:

- We decide to punt systemd by default to F-15.

In this case, maintaining systemd in F-14 actively hurts your ability to
fix it - you're punting it to F-15 so you can do more active development and
testing of it there. So, you'll have code in F-14 which either a) needs
constantly updated to match the testing codebase in F-15, possibly spreading
to other packages that interact with systemd, or b) is constantly out of date
and effectively unsupported/stillborn. So, in this case, I strongly suggest
only going with upstart in F-14, and systemd in F-15. (Perhaps set up
something on repos.fp.o for those that would want to test on F-14.)

- We decide to have systemd by default in F-14.

This case is a little different. However, if we're planning on dropping
upstart in F-15, does it help us to have it in F-14 to be maintained for the
life of the release, knowing that we're not planning on updating it,
ehancing it, or including it in a later release? It also causes problems for
documentation, in that all your documentation will have to have 'if upstart
do <foo>, if systemd do <bar>', etc.

Bill