Matthew Miller (mattdm(a)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