On 07/24/2012 10:28 AM, Jaroslav Reznik wrote:
----- Original Message -----
> We need to pay special attention to the half implementation of the
> preset feature  that Red Hat club that FESCO is, decided should
Red Hat Club? Mitr, the Red Hatter voted -1 because of "<mitr> kay: right,
and my election platform said "time-definite migrations". So I'm forced
to be -1" ;-)
Yes his vote is him standing true to his words it's not like he had a
lot of other options and unlike one of the FESCO members does, I do not
base my conclusion on there is a Red Hat Club on a single incident and
that's not limited to FESCO you can find it here ( QA ) as well...
> The feature it self is much needed and appreciated however not making
> the switch in a single release cycle after all the legacy sysv script
> have been migrated native systemd units will leave us in a pile of
> to deal with where *some*'packages ( and spins ) will use preset and
> others not.
It's still possible to implement it within single release cycle. Just
there has to be community buy in. And at least spins with DMs would
have to step into.
Arguably FESCO should be reaching out the community and get the buy in (
or at least some feedback ) before approving features that require
community buy in the first place.
( And yes I'm very well aware of the downside of this approach ) which
would ensure smoother process implementing those features.
This is just one of those features that need to be a) implement in one
release cycle and b) *after* we have finished migrating all the legacy
sysv init scripts. We dont need yet another half implemented feature
that claims to be 100% done and certainly not this one. We need to
implement this in one release cycles as mitr correctly points out there
on the talk page to limit the disruption this has to our user base which
is the one if not the most important lesson we can learn from the sysv
to systemd migration process.
And as I said before we need to pay very close attention to the
migration process from the rpm scriplets to the preset macro/files and
ensure that users previous settings where services where either enabled
or disable wont get enabled/disabled on upgrade in the process and how
this for example will affect masked units etc.