FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-03-2011, 01:46 PM
Reindl Harald
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
is at 0% - why will F16 released WITHOUT making the system clean which
should have been done for F15

How many releases will this dirty mix of systemd/sysvinit(lsb in the
distribution exist until the OS can be called as "clean" like before
F15?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 05:14 PM
Stephen John Smoogen
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

On Sat, Sep 3, 2011 at 07:46, Reindl Harald <h.reindl@thelounge.net> wrote:
> the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
> is at 0% - why will F16 released WITHOUT making the system clean which
> should have been done for F15
>
> How many releases will this dirty mix of systemd/sysvinit(lsb in the
> distribution exist until the OS can be called as "clean" like before
> F15?

As many as it takes to get it done.



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 09:47 PM
Kevin Kofler
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

Stephen John Smoogen wrote:
> On Sat, Sep 3, 2011 at 07:46, Reindl Harald <h.reindl@thelounge.net>
> wrote:
>> the alpha was release and
>> http://fedoraproject.org/wiki/Features/SysVtoSystemd is at 0% - why will
>> F16 released WITHOUT making the system clean which should have been done
>> for F15
>>
>> How many releases will this dirty mix of systemd/sysvinit(lsb in the
>> distribution exist until the OS can be called as "clean" like before
>> F15?
>
> As many as it takes to get it done.

We need to get a provenpackager to just poke through all the packages and
fix them instead of waiting for the maintainers.

We should also remove this stupid "cannot migrate to a native systemd unit
in an update" rule. If a native systemd unit file gets written, it should be
pushed out to F16 and F15 immediately.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-04-2011, 12:20 AM
Tom Lane
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

Kevin Kofler <kevin.kofler@chello.at> writes:
> Stephen John Smoogen wrote:
>> On Sat, Sep 3, 2011 at 07:46, Reindl Harald <h.reindl@thelounge.net>
>> wrote:
>>> How many releases will this dirty mix of systemd/sysvinit(lsb in the
>>> distribution exist until the OS can be called as "clean" like before
>>> F15?

>> As many as it takes to get it done.

> We need to get a provenpackager to just poke through all the packages and
> fix them instead of waiting for the maintainers.

That doesn't seem to me to be a very good idea. Having recently worked
on the systemd migrations for mysql and postgresql, I know that there
are frequently package-specific considerations that are not obvious to
the casual onlooker. Having somebody who thinks he knows what he's
doing hack all the unfixed services is likely to make things worse not
better.

> We should also remove this stupid "cannot migrate to a native systemd unit
> in an update" rule. If a native systemd unit file gets written, it should be
> pushed out to F16 and F15 immediately.

That policy annoyed me at first but I've seen the wisdom of it. Doing
something like that will very likely break users' customizations of
their service setups, which is not something you want to have happen
after a routine "yum update".

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-04-2011, 12:59 AM
Reindl Harald
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

Am 04.09.2011 02:20, schrieb Tom Lane:
> Kevin Kofler <kevin.kofler@chello.at> writes:
>> Stephen John Smoogen wrote:
>>> On Sat, Sep 3, 2011 at 07:46, Reindl Harald <h.reindl@thelounge.net>
>>> wrote:
>>>> How many releases will this dirty mix of systemd/sysvinit(lsb in the
>>>> distribution exist until the OS can be called as "clean" like before
>>>> F15?
>
>>> As many as it takes to get it done.
>
>> We need to get a provenpackager to just poke through all the packages and
>> fix them instead of waiting for the maintainers.
>
> That doesn't seem to me to be a very good idea. Having recently worked
> on the systemd migrations for mysql and postgresql, I know that there
> are frequently package-specific considerations that are not obvious to
> the casual onlooker. Having somebody who thinks he knows what he's
> doing hack all the unfixed services is likely to make things worse not
> better.
>
>> We should also remove this stupid "cannot migrate to a native systemd unit
>> in an update" rule. If a native systemd unit file gets written, it should be
>> pushed out to F16 and F15 immediately.
>
> That policy annoyed me at first but I've seen the wisdom of it. Doing
> something like that will very likely break users' customizations of
> their service setups, which is not something you want to have happen
> after a routine "yum update"

this wisdom is a little too late and should have been there before
forcing the switch - no as we have systemd if we want it or not
it must not take years to get all services converted

hopefully the next time a big change like i fear wayland will be
is introduced this wisdom comes BEFORE release

give out a notice or somewaht else if a package brings a new
systemd-service but stop tell us we have to wait until F17 or F18
to get the state which should have been for F15






--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-04-2011, 03:25 PM
Marcos Mello
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

Reindl Harald <h.reindl <at> thelounge.net> writes:

>
> the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
> is at 0% - why will F16 released WITHOUT making the system clean which
> should have been done for F15
>
> How many releases will this dirty mix of systemd/sysvinit(lsb in the
> distribution exist until the OS can be called as "clean" like before
> F15?
>
>
>

The following page appears to have an updated status:

https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 02:55 AM
Bill Nottingham
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

Reindl Harald (h.reindl@thelounge.net) said:
> the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
> is at 0% - why will F16 released WITHOUT making the system clean which
> should have been done for F15

Perhaps the feature owner should update it, as per the policy.

> How many releases will this dirty mix of systemd/sysvinit(lsb in the
> distribution exist until the OS can be called as "clean" like before
> F15?

The entire point of having a system that supports sysv init scripts
natively, supports having dependencies between sysv and systemd,
and so on, is so you DON'T have to do a rushed migration.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 04:27 AM
"Jˇhann B. Gu­mundsson"
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

On 09/06/2011 02:55 AM, Bill Nottingham wrote:
> Reindl Harald (h.reindl@thelounge.net) said:
>> the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
>> is at 0% - why will F16 released WITHOUT making the system clean which
>> should have been done for F15
> Perhaps the feature owner should update it, as per the policy.

I was planning on updating that 0% after beta ( as opposed to having to
go through all the components twice or more and incrementally increase
that number for no purpose).

Once we have released beta you either have native systemd unit for the
component or you wont for the F16 whole release cycle and % number on a
wiki page aint gonna change that.

Live media + default next next install should be covered except for
openvpn and wpa_supplicant.

That in it self is an acceptable milestone to have reached in my books
in one release cycle as in all hands out media + desktop install have
been converted and are covered.

Depending on the rest of the components and their maintainers rest might
take sometime on converting for variety of reasons.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 05:50 AM
"Jˇhann B. Gu­mundsson"
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

On 09/03/2011 09:47 PM, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>> On Sat, Sep 3, 2011 at 07:46, Reindl Harald<h.reindl@thelounge.net>
>> wrote:
<snip>..
> We need to get a provenpackager to just poke through all the packages and
> fix them instead of waiting for the maintainers.

In some cases that would work ( as in if the maintainer would sanction
the unit file and a proven packager would take care of packaging and
shipping it my wiki page was prepared for such an scenario ) but
knowing first hand and as I have mentioned before we cant do that with
one exception and that is in the case of nonresponsive maintainers.

What's slowing the adoption of systemd aren't the responsive maintainers
which are looking into this, it's the non responsive ones.

Once a maintainer becomes unresponsive it causes major pain and resource
drain across various groups within the community.

When that happens to the maintainer ( or any person for that matter ) he
should reduce his load and drop the component(s) or reach out to the
community for co-maintainer ship or other potential needs he requires to
reduce his loads and reach/keep the right balance he needs.

If he does not he is just causing himself unneeded stress in his life
which will eventually lead to an burnout and potential other
complications in his personal life and potentially to his own health.

Unfortunately people have a hard time realizing ( and react ) when they
are in that situation until it's too late and they find themselves
sitting in a darkroom alone popping pills staring endlessly at the
monitor while an lynchmob of needy/greedy users with torches are
knocking on their door demanding more of that free coolaid...

Unfortunately afaik we arent helping in that regards as in putting limit
on how many components you can maintain in the distro and so on and so
fourth to help preventing ( or at least reducing likelihood of )
scenarios like that to happen.

There is one thing I have learned ( so far in the conversion process )
and that is that the current model surrounding maintainers and
maintainership followed by various policies surrounding that model which
we use here in Fedora as in maintainers "Own" their components (
ownership model ) cannot deal with large scale changes like systemd
introduces amongst other things and I will go so far to say that module
effectively became outdated when Fedora stopped being hobby distro (
which happened the instance people/corporates started depending on
fedora and the components it ships which kinda says it never was ) made
up of relatively few components with relatively few maintainers and an
hand full of users but that discussion belongs in another thread.

> We should also remove this stupid "cannot migrate to a native systemd unit
> in an update" rule. If a native systemd unit file gets written, it should be
> pushed out to F16 and F15 immediately.
>

With my QA hat on I nack such an proposal in an instance...

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 05:50 AM
"Jˇhann B. Gu­mundsson"
 
Default http://fedoraproject.org/wiki/Features/SysVtoSystemd

On 09/03/2011 09:47 PM, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>> On Sat, Sep 3, 2011 at 07:46, Reindl Harald<h.reindl@thelounge.net>
>> wrote:
<snip>..
> We need to get a provenpackager to just poke through all the packages and
> fix them instead of waiting for the maintainers.

In some cases that would work ( as in if the maintainer would sanction
the unit file and a proven packager would take care of packaging and
shipping it my wiki page was prepared for such an scenario ) but
knowing first hand and as I have mentioned before we cant do that with
one exception and that is in the case of nonresponsive maintainers.

What's slowing the adoption of systemd aren't the responsive maintainers
which are looking into this, it's the non responsive ones.

Once a maintainer becomes unresponsive it causes major pain and resource
drain across various groups within the community.

When that happens to the maintainer ( or any person for that matter ) he
should reduce his load and drop the component(s) or reach out to the
community for co-maintainer ship or other potential needs he requires to
reduce his loads and reach/keep the right balance he needs.

If he does not he is just causing himself unneeded stress in his life
which will eventually lead to an burnout and potential other
complications in his personal life and potentially to his own health.

Unfortunately people have a hard time realizing ( and react ) when they
are in that situation until it's too late and they find themselves
sitting in a darkroom alone popping pills staring endlessly at the
monitor while an lynchmob of needy/greedy users with torches are
knocking on their door demanding more of that free coolaid...

Unfortunately afaik we arent helping in that regards as in putting limit
on how many components you can maintain in the distro and so on and so
fourth to help preventing ( or at least reducing likelihood of )
scenarios like that to happen.

There is one thing I have learned ( so far in the conversion process )
and that is that the current model surrounding maintainers and
maintainership followed by various policies surrounding that model which
we use here in Fedora as in maintainers "Own" their components (
ownership model ) cannot deal with large scale changes like systemd
introduces amongst other things and I will go so far to say that module
effectively became outdated when Fedora stopped being hobby distro (
which happened the instance people/corporates started depending on
fedora and the components it ships which kinda says it never was ) made
up of relatively few components with relatively few maintainers and an
hand full of users but that discussion belongs in another thread.

> We should also remove this stupid "cannot migrate to a native systemd unit
> in an update" rule. If a native systemd unit file gets written, it should be
> pushed out to F16 and F15 immediately.
>

With my QA hat on I nack such an proposal in an instance...

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org