WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
sometimes it seems nobody cares about GA-Releases to have arguments updating to the next as soon as possible where all will be better and the things which are worse are better in the release after the release
PLEASE fix bugs in GA-Releases instead working permanently only in rawhide!
systemd-33-2.fc16 systemd-33-1.fc16 systemd-32-1.fc17 systemd-32-1.fc16 systemd-31-2.fc16 systemd-31-1.fc16 systemd-30-1.fc16 systemd-26-8.fc15
Hi,
2011/8/20 Reindl Harald h.reindl@thelounge.net:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
It's maintained - serious bugs are fixed.
F15 is SEVEN versions behind!
sometimes it seems nobody cares about GA-Releases to have arguments updating to the next as soon as possible where all will be better and the things which are worse are better in the release after the release
PLEASE fix bugs in GA-Releases instead working permanently only in rawhide!
systemd-33-2.fc16 systemd-33-1.fc16 systemd-32-1.fc17 systemd-32-1.fc16 systemd-31-2.fc16 systemd-31-1.fc16 systemd-30-1.fc16 systemd-26-8.fc15
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, 20.08.11 16:25, Reindl Harald (h.reindl@thelounge.net) wrote:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora.
Lennart
Am 20.08.2011 19:58, schrieb Lennart Poettering:
On Sat, 20.08.11 16:25, Reindl Harald (h.reindl@thelounge.net) wrote:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora.
the problem is that wat you call "as intedned", "a bug" and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later
2011/8/20 Reindl Harald h.reindl@thelounge.net:
Am 20.08.2011 19:58, schrieb Lennart Poettering:
On Sat, 20.08.11 16:25, Reindl Harald (h.reindl@thelounge.net) wrote:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora.
the problem is that wat you call "as intedned", "a bug" and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later
If you want a new features just build it or use F16 branch.
Most F15 users don't want to deal with new systemd bugs in stable system.
Am 20.08.2011 20:49, schrieb Michał Piotrowski:
2011/8/20 Reindl Harald h.reindl@thelounge.net:
Am 20.08.2011 19:58, schrieb Lennart Poettering:
On Sat, 20.08.11 16:25, Reindl Harald (h.reindl@thelounge.net) wrote:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora.
the problem is that wat you call "as intedned", "a bug" and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later
If you want a new features just build it or use F16 branch.
Most F15 users don't want to deal with new systemd bugs in stable system.
jokingly?
nobody wanted a text-desert at boot nobody wanted a "systemctl anything service" without feedback nobody wanted a /sbin/service-wrapper which ALWAYS says OK even on fail nobody wanted to fire up services with sockets after "systemctl stop something.service" nobody wanted a bott with no progress while fs-check is active
if you release this crap way too soon in a production release you are responsible to fix this bad attitudes in the same fedora-release or consider BEFORE the GA not spit in the users face with making perfectly working things worser because YOU are thinking that all is better (in theory)
Am 20.08.2011 20:49, schrieb MichaÅ Piotrowski:
2011/8/20 Reindl Harald h.reindl@thelounge.net:
Am 20.08.2011 19:58, schrieb Lennart Poettering:
On Sat, 20.08.11 16:25, Reindl Harald (h.reindl@thelounge.net) wrote:
WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer?
F15 is SEVEN versions behind!
Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora.
the problem is that wat you call "as intedned", "a bug" and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later
If you want a new features just build it or use F16 branch.
Most F15 users don't want to deal with new systemd bugs in stable system.
jokingly?
nobody wanted a text-desert at boot nobody wanted a "systemctl anything service" without feedback nobody wanted a /sbin/service-wrapper which ALWAYS says OK even on fail nobody wanted to fire up services with sockets after "systemctl stop something.service" nobody wanted a bott with no progress while fs-check is active
if you release this crap way too soon in a production release you are responsible to fix this bad attitudes in the same fedora-release or consider BEFORE the GA not spit in the users face with making perfectly working things worser because YOU are thinking that all is better (in theory)
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug.
Of course, "I don't like this, it's different" isn't a bug, and there's a substantial amount of backwards-compatibility built in here. I've been restarting services with /etc/rc.d/init.d/foodaemond restart for ages. It's what my fingers like. And it still works. "Better" and "Worse" are not things that anyone can take action on. Specific problems introduced are. If you can say, "This used to be A, and now it's B, and when it changed, it broke C, and nothing in the documentation tells me how to make C work with B", file a bug. You may have to make changes to make C work with B. You may not. I actually found that I did, but oddly all the things I needed to learn made things easier. The move from SysV initscripts to unit files alone is wonderful.
In this case, there have been real benefits to changing A to B, and the kinks remaining to be worked out are becoming fewer daily. It's not perfect, but it's a lot better than it could be.
Additionally, it's not like the move to systemd was announced on 15GA day. The volume of discussion, troubleshooting, flaming, and problem resolution that went on on lists, in BZ, and email prior to that is impressive.
</cranky_rant>
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Am 21.08.2011 22:07, schrieb Jon Ciesla:
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug
most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers
i am one of them and i am seeing NOTHING happen in F15 now to make things better until Dec/Jan and the wrapper you noticed about /etc/init.d/servicename is the dumbest thing i saw the last years because it hides the real output of the script
Am 21.08.2011 22:07, schrieb Jon Ciesla:
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug
most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers
Fedora? Production? I do that, but I'm mental.
i am one of them and i am seeing NOTHING happen in F15 now to make things better until Dec/Jan and the wrapper you noticed about /etc/init.d/servicename is the dumbest thing i saw the last years because it hides the real output of the script
It's less than ideal, yes, so I use service whateverd restart now.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Am 22.08.2011 16:36, schrieb Jon Ciesla:
Am 21.08.2011 22:07, schrieb Jon Ciesla:
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug
most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers
Fedora? Production? I do that, but I'm mental
yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external
per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts
but F15 is the first release where this feels really ugly with no benefit anywhere until now
Am 22.08.2011 16:36, schrieb Jon Ciesla:
Am 21.08.2011 22:07, schrieb Jon Ciesla:
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug
most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers
Fedora? Production? I do that, but I'm mental
yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external
per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts
Agreed. But it's not for everyone. ;)
but F15 is the first release where this feels really ugly with no benefit anywhere until now
"Feels"? So. . .you have to change your helper scripts? I'm confused.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Am 23.08.2011 15:36, schrieb Jon Ciesla:
Fedora? Production? I do that, but I'm mental
yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external
per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts
Agreed. But it's not for everyone. ;)
maybe, but i am not everyone - i know exactly what i do and something goes terrible wrong if the really expierienced users have more troubles as some standard desktop-user
but F15 is the first release where this feels really ugly with no benefit anywhere until now
"Feels"? So. . .you have to change your helper scripts? I'm confused
my self written watchdog which detects reboot/shutdown and calls of /sbin/service doe snot work any longer and this script is simply perfect restarting services and giving the result of /sbin/service out results in a perfectly cron mail
with systemd - not possible, if systemd is reastrting a service you get NOT notfied - this is essential because it is one thing a service is fired up again automatically but if you are not notified and this happens to often you will not recognize this
below a example
Betreff: Cron root@myhost php /scripts/rh_watchdog.php Datum: Tue, 5 Jul 2011 17:38:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain
"httpd" not running, waiting 5 seconds and restart if it not comes back httpd beenden: [FEHLGESCHLAGEN] httpd: no process found httpd starten: [ OK ]
___________________________
services with .socket-files are NOT stopped with "systemctl stop name.service" and suddenly fired up and the missing feddback of "systemctl" is bad
below a example-mail of a weekly job stopping two mysqld-instances on a machine (one of them replication-slave) and let rsync backup# the replication into the other one - this have to be totally changed
Betreff: Cron root@myhost nice -n 19 bash /opt/scripts/backup-mysql.sh Datum: Sat, 2 Jul 2011 03:10:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain
Sat Jul 2 03:10:01 CEST 2011 mysqld beenden: [ OK ] replication beenden: [ OK ] replication starten: [ OK ] mysqld starten: [ OK ] Sat Jul 2 03:24:33 CEST 2011
there are tons of such scripts running perfectly since years and all of that has to be changed/replaced/retested because of systemd without any real benefit at this time
Am 23.08.2011 15:36, schrieb Jon Ciesla:
Fedora? Production? I do that, but I'm mental
yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external
per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts
Agreed. But it's not for everyone. ;)
maybe, but i am not everyone - i know exactly what i do and something goes terrible wrong if the really expierienced users have more troubles as some standard desktop-user
but F15 is the first release where this feels really ugly with no benefit anywhere until now
"Feels"? So. . .you have to change your helper scripts? I'm confused
my self written watchdog which detects reboot/shutdown and calls of /sbin/service doe snot work any longer and this script is simply perfect restarting services and giving the result of /sbin/service out results in a perfectly cron mail
with systemd - not possible, if systemd is reastrting a service you get NOT notfied - this is essential because it is one thing a service is fired up again automatically but if you are not notified and this happens to often you will not recognize this
below a example
Betreff: Cron root@myhost php /scripts/rh_watchdog.php Datum: Tue, 5 Jul 2011 17:38:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain
"httpd" not running, waiting 5 seconds and restart if it not comes back httpd beenden: [FEHLGESCHLAGEN] httpd: no process found httpd starten: [ OK ]
services with .socket-files are NOT stopped with "systemctl stop name.service" and suddenly fired up and the missing feddback of "systemctl" is bad
below a example-mail of a weekly job stopping two mysqld-instances on a machine (one of them replication-slave) and let rsync backup# the replication into the other one - this have to be totally changed
Betreff: Cron root@myhost nice -n 19 bash /opt/scripts/backup-mysql.sh Datum: Sat, 2 Jul 2011 03:10:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain
Sat Jul 2 03:10:01 CEST 2011 mysqld beenden: [ OK ] replication beenden: [ OK ] replication starten: [ OK ] mysqld starten: [ OK ] Sat Jul 2 03:24:33 CEST 2011
there are tons of such scripts running perfectly since years and all of that has to be changed/replaced/retested because of systemd
So they need to be changed, yes. A pain, but. . .
without any real benefit at this time
. . .to you, perhaps. For many, however.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, Aug 21, 2011 at 14:20, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.08.2011 22:07, schrieb Jon Ciesla:
Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug
most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers
Your emails are coming across as jumping up and down and screaming. All that is going to accomplish is getting people to tune you out. If you want Fedora to be a server OS then you need to work at it in a better fashion or go find something else that will make you happy.