Init Systems GR Timeline
> "Holger" == Holger Levsen writes: Holger> On Thu, Nov 07Holger> Finally, I don't think it's a good idea to rush this to a Holger> vote in 7 days. I'm tempted to mail d-d-a to make people who Holger> are not regularily read -vote aware of this Holger> discussion. (There are also many people who don't read Holger> -devel.) Sam, I'd appreciate if I wouldn't need to do that, Holger> because you sent such a short pointer to -vote on d-d-a I think you may be mishearing what I'm proposing for a timeline. I'm proposing seven days of collecting entirely informal comments; that can be extended if there are still significant open issues. Then, starting a formal process. Assuming no extensions, that means two weeks of discussion and amendments, followed by two weeks of vote. The secretary will send mail to d-d-a when the formal discussion period starts. I don't plan to send mail to d-d-a before that, but if someone feels this needs more exposure on d-d-a now then by all means send a quick note. I don't have the power to call for a vote in 7 days, and agree with you that doing so even if I could would be a bad idea.
Re: [draft] Draft text on Init Systems GR
Hello, On Fri 08 Nov 2019 at 06:04PM +01, Ansgar wrote: > No, but maybe I expressed myself badly: we have people that complain > that building Debian source packages with a Debian-specific command is a > too high burden. This is independent of how source is represented (Git, > .dsc, rpm, Git+LFS, only-debian/-Git+tar, references to external > artifacts, ...). > > So some people believe that "Debian-specific tooling is bad", even for > Debian-specific work. Thanks for the clarification -- I see what you mean now. -- Sean Whitton signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
Sean Whitton writes: > On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote: >> We already have people complaining that source packages are "too Debian >> specific" and should be replaced. The tooling above is even more of a >> problem as third parties currently have to deal with way too many >> different ways to even before getting to packaging which is inherently >> more package-manager- and thus distribution(-familiy)-specific. > > If you're referring to those of us who aren't keen on the .dsc transport > format, I think that the point is orthogonal. What we're talking about > in this thread is the contents of binary packages. No, but maybe I expressed myself badly: we have people that complain that building Debian source packages with a Debian-specific command is a too high burden. This is independent of how source is represented (Git, .dsc, rpm, Git+LFS, only-debian/-Git+tar, references to external artifacts, ...). So some people believe that "Debian-specific tooling is bad", even for Debian-specific work. > The reasons that there might be for reducing the amount of > Debian-specific stuff in binary packages are quite different from the > reasons for reducing the amount of Debian-specific stuff used in moving > source code around. > > The basic reason for that is that what we are trying to produce is an > operating system composed, roughly, of binary packages; we have produced > ways to move source code around only incidentally to that. Yes, and the software that gets packaged needs to interact with the rest of an operating system in ways that upstream has to deal with. They benefit from common tooling across several distributions. Additionally it also reduces workload for people maintaining software in Debian. In my opinion enabling the use of such tooling is quite useful and a logical continuation of what already happened with, for example, abstraction layers around session management for desktop environments. Note that Debian already adopted these. We also decreased use of Debian-specific tools such as the Debian-specific menu system. In some way this is "Debian-specific tooling is bad for tasks that are not Debian-specific", that is a weaker version of the position above. (This doesn't mean we shouldn't decrease Debian-specific tooling for Debian-specific work if we can reasonably do so.) Ansgar
Re: [draft] Draft text on Init Systems GR
Hello, On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote: > We already have people complaining that source packages are "too Debian > specific" and should be replaced. The tooling above is even more of a > problem as third parties currently have to deal with way too many > different ways to even before getting to packaging which is inherently > more package-manager- and thus distribution(-familiy)-specific. If you're referring to those of us who aren't keen on the .dsc transport format, I think that the point is orthogonal. What we're talking about in this thread is the contents of binary packages. The reasons that there might be for reducing the amount of Debian-specific stuff in binary packages are quite different from the reasons for reducing the amount of Debian-specific stuff used in moving source code around. The basic reason for that is that what we are trying to produce is an operating system composed, roughly, of binary packages; we have produced ways to move source code around only incidentally to that. -- Sean Whitton signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
Holger Levsen writes: > On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: >> >> version 2330c05afa4 [...] >> Choice 3: systemd without Diversity as a Priority > [...] > > I guess this option will get ammendments: > > a.) 'systemd without diversity as a priority' sounds like systemd is > against diversity. I think this is borderline insulting. So I expect > this will attract someone proposing another option called 'Embrace > the future (*) and a modern init system' or such. > *) or 'Embrace new technologies...' [...] > On top of all of this, systemd provides much more features than unit > files as the thread on -devel showed. There is no word about these > technologies in this GR proposal. I think that's a flaw in this > proposal. Maybe something along the lines of "Embrace tooling diversity and cross-distribution collaboration"? This is about allowing experimenting with and possibly adopting new tools (sysusers, tmpfiles, ...) and making cross-distribution work easier by standardizing "boring" aspects of packaging such as how to create service accounts. We already have people complaining that source packages are "too Debian specific" and should be replaced. The tooling above is even more of a problem as third parties currently have to deal with way too many different ways to even before getting to packaging which is inherently more package-manager- and thus distribution(-familiy)-specific. On the other side, we have Debian-specific, least common denominator tooling that is hard to change. Ansgar
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > version 2330c05afa4 > Choice 1: Affirm Init Diversity [...] looks generally like a fine option to me. > Choice 2: systemd but we Support Exploring Alternatives [...] as others have said, this mixes init systems with systemd-logind. > Choice 3: systemd without Diversity as a Priority [...] I guess this option will get ammendments: a.) 'systemd without diversity as a priority' sounds like systemd is against diversity. I think this is borderline insulting. So I expect this will attract someone proposing another option called 'Embrace the future (*) and a modern init system' or such. *) or 'Embrace new technologies...' b.) I guess some will want something like this option on the ballot but without the commitment about working with downstreams _worded this way_. c.) Some will not want 'Packages should include service units or init scripts to start daemons and services' but rather a much stronger recommendation to drop init scripts and ship unit files. On top of all of this, systemd provides much more features than unit files as the thread on -devel showed. There is no word about these technologies in this GR proposal. I think that's a flaw in this proposal. Then, I think the ballot also misses an option for the sysv-lovers, 'Embrace systems without systemd' or some such, which explicitly forbids using systemd technology without alternative support working on sysv systems. I think it would be very useful to know whether 0.5, 5%, or 15% or 25% (or more?) of our developers think such would be a good choice. Finally, I don't think it's a good idea to rush this to a vote in 7 days. I'm tempted to mail d-d-a to make people who are not regularily read -vote aware of this discussion. (There are also many people who don't read -devel.) Sam, I'd appreciate if I wouldn't need to do that, because you sent such a short pointer to -vote on d-d-a *before* calling for a vote. Like now. Last, and definitly not least: many thanks for working on this, Sam. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
why mention Constitution section 4.1 (5 or even 4)? (Re: [draft] Draft text on Init Systems GR)
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > version 2330c05afa4 > > Using its power under Constitution section 4.1 (5) I fail to see why Constitution section 4.1 (5) is referred here. I'd better understand section 4.1 (4) and would probably would prefer to leave out this half sentence completly. (I'll comment on other aspects seperately if I have more comments.) Thanks. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
