systemd-sysv/shim in testing
Greetings everyone, As brought up in this[0] thread, systemd-shim became incompatible with the latest versions of systemd and the alternative dependency was removed. While this is something I can totally understand, I don't think that systemd should migrate to testing without the possibility to use systemd-shim instead. My reasoning about this is as follows: Testing should be as close to a state in which it can be released as possible (I don't have a citation for that and just remember that I did read that somewhere, so please correct me if I'm wrong). Further we are not planning to release jessie without systemd-shim (at least I hope so, again please correct me if I'm wrong). This shouldn't be a huge problem, since waiting a week longer until systemd migrates shouldn't be that much of a problem, while it makes the risk smaller to accidentally remove your desktop-environment at a dist-upgrade (that's at least what apt wanted to do on my computer). To make it short: I suggest that systemd should only migrate together with systemd-shim. [0]: https://lists.debian.org/debian-devel/2014/07/msg00839.html Regards Sven signature.asc Description: PGP signature
Re: systemd-sysv/shim in testing
To make it short: I suggest that systemd should only migrate together with systemd-shim. ACK! -nik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8667e39c-b7ef-4b9a-a686-f3c41f0ea...@email.android.com
Re: systemd-sysv/shim in testing
El Sun, 27 de Jul 2014 a las 11:23 AM, Sven Bartscher sven.bartsc...@weltraumschlangen.de escribió: Greetings everyone, As brought up in this[0] thread, systemd-shim became incompatible with the latest versions of systemd and the alternative dependency was removed. While this is something I can totally understand, I don't think that systemd should migrate to testing without the possibility to use systemd-shim instead. My reasoning about this is as follows: Testing should be as close to a state in which it can be released as possible (I don't have a citation for that and just remember that I did read that somewhere, so please correct me if I'm wrong). Further we are not planning to release jessie without systemd-shim (at least I hope so, again please correct me if I'm wrong). This shouldn't be a huge problem, since waiting a week longer until systemd migrates shouldn't be that much of a problem, while it makes the risk smaller to accidentally remove your desktop-environment at a dist-upgrade (that's at least what apt wanted to do on my computer). To make it short: I suggest that systemd should only migrate together with systemd-shim. [0]: https://lists.debian.org/debian-devel/2014/07/msg00839.html Regards Sven Greetings, Although I personally agree that personal choice of init system is important for the distribution, by a 4-4 vote, the TC decided not to make dependencies on one init system as PID Eins (1) (i.e. systemd-sysv) a release critical bug. I believe some of the reasons were that the move was preemptive (as systemd 204 was the current systemd version), or not in the scope of the TC (specifying the exact severity *is* a bit much). Instead, the TC voted to not rule on the matter. I believe the choices are to repose the question to the TC, now that the situation has actually occurred, or begin a General Resolution. As far as I understand, a GR would only need a majority since the TC did not really make a ruling. Best wishes, -- Cameron Norman
Re: systemd-sysv/shim in testing
Hi, On Sonntag, 27. Juli 2014, Dominik George wrote: To make it short: I suggest that systemd should only migrate together with systemd-shim. ACK! I think you missed the mail (on this list) which explained that systemd has been waiting for 6 months for systemd-shim to catch up. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: systemd-sysv/shim in testing
Cameron Norman camerontnor...@gmail.com writes: I believe the choices are to repose the question to the TC, now that the situation has actually occurred, or begin a General Resolution. As far as I understand, a GR would only need a majority since the TC did not really make a ruling. The release team can decide on testing migration schedules and on release-critical bugs following their normal processes. That was part of the point of the TC not ruling: the project should follow its normal processes and do its normal good job of balancing the conflicts between getting the right software into the next release and keeping the release stable. The timing of migration of the new version of systemd to testing, like questions about testing migration in general, is really a release team decision. They may want the new systemd to get into testing for broader testing ASAP, or they may want to use this as an opportunity to test the upgrade process that we expect stable users to go through (in which case waiting for systemd-shim may make sense), or they may have some other opinion or goal. Regardless, it's up to them; this is their bailiwick, obviously with the opinions of the maintainers of the relevant packages taken into account. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2cq4mv7@windlord.stanford.edu
Re: systemd-sysv/shim in testing
On Sun, 27 Jul 2014 21:21:56 +0200 Holger Levsen hol...@layer-acht.org wrote: Hi, On Sonntag, 27. Juli 2014, Dominik George wrote: To make it short: I suggest that systemd should only migrate together with systemd-shim. ACK! I think you missed the mail (on this list) which explained that systemd has been waiting for 6 months for systemd-shim to catch up. Yeah, I kind of missed that. It's right that my suggestion is not going to work if systemd-shim is that much behind. As a solution I would suggest that a few more people help with the development of the shim. (Of course, only if that's alright for the current maintainer.) For this matter I would offer my help for issues of this kind in the future, in the hope that we will be able to keep the shim up to date with systemd without blocking it too much. Regards Sven signature.asc Description: PGP signature
Re: systemd-sysv/shim in testing
* Russ Allbery (r...@debian.org) [140727 21:51]: The timing of migration of the new version of systemd to testing, like questions about testing migration in general, is really a release team decision. And the release team has done a decision for the normal case when bugs are release critical (i.e. block testing migration) and when not. Please see https://release.debian.org/jessie/rc_policy.txt for the definition. Of course, they might override it in special cases. But all of that is the normal release process, even overriding release criticality by the release team, and nothing is special. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140727203625.gg20...@mails.so.argh.org
Re: systemd-sysv/shim in testing
2014-07-27 22:08 GMT+02:00 Sven Bartscher sven.bartsc...@weltraumschlangen.de: On Sun, 27 Jul 2014 21:21:56 +0200 Holger Levsen hol...@layer-acht.org wrote: Hi, On Sonntag, 27. Juli 2014, Dominik George wrote: To make it short: I suggest that systemd should only migrate together with systemd-shim. ACK! I think you missed the mail (on this list) which explained that systemd has been waiting for 6 months for systemd-shim to catch up. Yeah, I kind of missed that. It's right that my suggestion is not going to work if systemd-shim is that much behind. As a solution I would suggest that a few more people help with the development of the shim. (Of course, only if that's alright for the current maintainer.) For this matter I would offer my help for issues of this kind in the future, in the hope that we will be able to keep the shim up to date with systemd without blocking it too much. That would, in fact, completely solve the issue and help everyone :-) And I am pretty sure the -shim maintainers are glad for every helping hand. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKNHny_=pe+olugyhtg5tdi9ryudm_-jy38eerywjbq4-oq...@mail.gmail.com
Re: systemd-sysv/shim in testing
Sven Bartscher wrote: As brought up in this[0] thread, systemd-shim became incompatible with the latest versions of systemd and the alternative dependency was removed. While this is something I can totally understand, I don't think that systemd should migrate to testing without the possibility to use systemd-shim instead. My reasoning about this is as follows: Testing should be as close to a state in which it can be released as possible (I don't have a citation for that and just remember that I did read that somewhere, so please correct me if I'm wrong). That's an accurate description of testing. systemd-shim isn't currently in a releasable state, but that's entirely on systemd-shim to fix. (The current round of incompatibility appears fixed in unstable, along with the inclusion of cgmanager, though there are apparently still a number of bugs in cgmanager; see https://lists.debian.org/debian-devel/2014/07/msg00957.html .) Along the same lines, systemd also currently has a pair of RC bugs on it, though both have patches that just need uploading. I feel certain that'll happen long before it affects the jessie release. Testing propagation does take installability into account, but systemd-shim is installable in testing; it just doesn't serve its intended purpose of supporting systemd-less graphical desktop systems, hence why it has an RC bug that the current version in unstable should address once it propagates. Based on the RC bug policy for releasing testing as stable, either systemd-shim will have that bug fixed by the time a stable release rolls around, or if something goes horribly wrong then it'll be removed from testing, and either way testing will then be releasable. Further we are not planning to release jessie without systemd-shim (at least I hope so, again please correct me if I'm wrong). I would assume the systemd-shim maintainers would prefer not to see jessie released without systemd-shim, hence why they've uploaded a new version fixing its RC bug (along with the new upload of cgmanager). However, systemd-shim isn't a distro-wide release goal; it's a single package with a well-known alternative available. I don't see any particular reason why systemd-shim needs any more special treatment than other packages; either it'll be part of the release or it won't. At the moment, it seems quite likely that it'll be part of the release. We need to decouple the success of systemd and systemd-shim. Each one needs to succeed or fail on its own merits. The systemd maintainers provided a months-long delay for systemd-shim to catch up to 208 (which is not the current upstream version), but I certainly hope future versions of systemd do not incur further delays waiting for alternative init systems to catch up. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140727224209.GA26687@thin
