Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Al Dunsmuir wrote: I agree, provided you mean not necessarily by each package's maintainer. In some cases, folks working on the common goal do need the assistance of the package maintainer. Alternatively, the package maintainer may be able to make the required changes in a timely manner on their own. Of course, diligent package maintainers should be able to do the changes. We just should not wait forever for the lazy, too busy or simply recalcitrant ones. Package maintainers must not be allowed to emulate King Canute and attempt to hold back the tide of change. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On Sat, 2011-09-03 at 15:46 +0200, Reindl Harald 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? The feature page has not been edited since June. It's often the case that you can't entirely rely on those completion %ages. The tracker bug - https://bugzilla.redhat.com/show_bug.cgi?id=713562 - is a better place to monitor progress in this case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Hi, 2011/9/6 Jóhann B. Guðmundsson johan...@gmail.com: On 09/06/2011 02:55 AM, Bill Nottingham wrote: Reindl Harald (h.rei...@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. I created a service for wpa_supplicant. Is there something wrong with it? 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. Excellent job :) 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 -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On 09/06/2011 08:39 AM, Michał Piotrowski wrote: I created a service for wpa_supplicant. Is there something wrong with it? Nope Dan had sanctioned it but then another one appear upstream and as you know we try to avoid deviating from upstream. Not sure if Bill spoke with Dan about this ( I assume he did not since there has not been any movement there ) I know that I haven't. With regards to openvpn maintainer has been busy and openvpn might require some path work. ( If I can recall correctly then Suse guys needed to patch their instance ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Jóhann B. Guðmundsson wrote: 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. That's exactly why I'm saying that global changes should be done globally, not by each package's maintainer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Reindl Harald (h.rei...@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
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On 09/06/2011 02:55 AM, Bill Nottingham wrote: Reindl Harald (h.rei...@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
Re: 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 Haraldh.rei...@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
Re: 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
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Am 04.09.2011 02:20, schrieb Tom Lane: Kevin Kofler kevin.kof...@chello.at writes: Stephen John Smoogen wrote: On Sat, Sep 3, 2011 at 07:46, Reindl Harald h.rei...@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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On Sat, Sep 3, 2011 at 07:46, Reindl Harald h.rei...@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
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Kevin Kofler kevin.kof...@chello.at writes: Stephen John Smoogen wrote: On Sat, Sep 3, 2011 at 07:46, Reindl Harald h.rei...@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
