[systemd-devel] D-Bus system services: systemd, Upstart, the future

["Jóhann B. Guðmundsson"]

On 09/03/2011 12:51 PM, Lennart Poettering wrote:
> On Fri, 02.09.11 10:04, "Jóhann B. Guðmundsson" (johannbg at gmail.com) wrote:
>
>> For the record there will be no more native systemd unit files
>> introduced into the release ( F16 ) after we release beta and since
>> we have started composing test candidates for beta what's in the
>> release ( F16 ) now is pretty much what will be in it during it's
>> whole release cycle.
> Oh, I thought we had the full conversion as release requirement. I
> wasn't aware this didn't work out. Sorry for the confusion,
>

Fesco themselves approved to block the alpha release until all core, 
base and base-x + what's on the live media had been converted.

But when push came to shove FESCO back out of it as in blocking the 
release which should have been done since both openvpn and 
wpa_supplicant are on the live media and if they had any intention what 
so ever to reach that goal they could have stepped in themselves ( which 
btw fesco members should never have to do. ) package and shipped the 
remaining service that lacked native unit files since I had already 
submitted unit files to reach that goal.

Now the the biggest problem I have faced for speedy adoption so far are 
non responsive maintainers.

Once a maintainer becomes unresponsive it causes major pain across 
various groups within the community and not but not least to the end user.

I'm not sure how other distro's deal with that problem but our method is 
far from being efficient.

Anyway to put long story short what I have learned so far is that the 
current model surrounding maintainers and maintainership followed by 
various policies surrounding that model which is used in Fedora as in 
maintainers "Own" their components ( ownership model ) cannot deal with 
large scale changes like systemd introduces amongst other things and 
that module effectively became outdated when Fedora stopped being hobby 
distro made up of relatively few components with relatively few 
maintainers and users.

JBG