Add Sep & Oct meetings, as tentative

[debian-ctte.git] / meetings / 20140116 / debian-ctte.2014-01-16-17.58.log.txt

17:58:10 <dondelelcaro> #startmeeting
17:58:10 <MeetBot> Meeting started Thu Jan 16 17:58:10 2014 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:10 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:22 * keithp also managed to write a summary of my own personal deliberations on the init system topic
17:58:22 <dondelelcaro> #topic Who is here?
17:58:26 <bdale> fwiw, cjwatson provided regrets in-channel earlier
17:58:28 <dondelelcaro> Don Armstrong
17:58:29 <bdale> Bdale Garbee
17:58:36 <keithp> Keith Packard
17:58:38 <dondelelcaro> rra said he would be back in about 5
17:58:51 <bdale> keithp: blog post, email, or where?
17:58:56 <keithp> email
17:58:59 <keithp> just went out
17:59:04 <bdale> ah, ok, looking
17:59:08 <keithp> to bug 727708
17:59:44 * aba is here as well
17:59:47 * keithp has been suffering severe time-zone shift after two back-to-back red-eyes on the way home. Not doing that again.
18:00:02 <dondelelcaro> I think vorlon and Diziet are also here
18:00:03 <Trollinator> Are non-CTTE-members welcome to join the discussion?
18:00:10 <keithp> yes, vorlon waved earlier
18:00:12 <vorlon> yes
18:00:19 <vorlon> (Steve Langasek)
18:00:34 <dondelelcaro> #topic Next Meeting?
18:00:38 <Trollinator> good.
18:01:15 <aba> the 20th?
18:01:17 <dondelelcaro> The next meeting is currently scheduled for the date -d 'Thu Jan 30 18:00:00 UTC 2014'
18:01:40 <bdale> keithp: I don't see it yet
18:01:59 <vorlon> Trollinator: that was a 'yes' acknowledging that I'm here, not responding to your question. :)  Non-CTTE members are welcome, but please bear in mind that the purpose of this meeting is for discussion among the TC members
18:02:06 <aba> didn't arrive here yet either
18:02:19 <bdale> so we chose today as a special meeting to focus on the init discussion, but I'm not convinced having another meeting in Jan on general topics is necessary?
18:02:26 <aba> dondelelcaro: can we postpone that, I think it depends on the outcome of the init question when we need it?
18:02:34 <aba> that = this discussion
18:02:55 <Diziet> bdale: We have a number of general topics which are outstanding.
18:02:56 <dondelelcaro> bdale, aba: OK. I'll reraise that question of whether we need another one on the list when it gets closer
18:03:27 <aba> Diziet: let's see how long we take with the init topic, and if we could finish something else today or not
18:03:31 <dondelelcaro> yeah, we do have some other things, but I'm OK with not meeting if that's what people prefer; I'll just ask sometime later
18:03:42 <bdale> Diziet: the question, I guess, is whether any useful discussion can be had on those .. the last meeting seemed to be mostly reviewing assigned tasks nobody had made progress on
18:03:51 <Trollinator> vorlon: I see. Thanks.
18:03:53 <keithp> bdale: looks like debian grey-listed the mail
18:03:56 <Diziet> bdale: Not on those other topics today, no.
18:03:59 <Diziet> But right.
18:04:16 <Diziet> Let's carry on and argue about other topics later if there's time.
18:04:17 <dondelelcaro> #action dondelelcaro to ping about next meeting on ctte mailing list before it happens
18:04:25 <dondelelcaro> #topic #727708 Decide which init system to pick
18:04:30 <vorlon> the init system question is queue-starving any other TC work for me, and I expect it will continue to do so until the vote
18:04:35 <bdale> keithp: ok, no worries, but don't be shy about expressing opinions here that we can read about in more detail when your email clears the filters later
18:04:41 <keithp> wil do
18:04:52 <keithp> sorry the email was sent so close to the meeting time
18:05:14 <keithp> essential summary: debian needs to support multiple init systems, but should make systemd default on Linux
18:05:17 <Diziet> I have a copy of keithp's mail.  My own mail sent a few minutes before has made it to the BTS already; I guess keithp's will do too.
18:05:43 <dondelelcaro> first off, I'd like to apologize for not having met our deadline; I just finished applying for two grants yesterday, and have been swamped with them over the break. I will publish my current thoughts on friday
18:05:54 <aba> I haven't manage to put things into mail yet, but my summary is: if we make systemd default for linux, I don't think we could do upstart as default for !linux
18:06:07 <Diziet> aba: Really ?
18:06:09 <dondelelcaro> but I don't think any of that should hold up what we're doing today, as that's just going to decide which one I support
18:06:39 <aba> Diziet: because I'm not convinced upstart is an sustainable future. But you could try to convince me otherwise
18:06:54 <aba> ^ if we do systemd on linux
18:07:05 <rra> Back, catching up.
18:07:05 <aba> I think we could do upstart everywhere, that would work
18:07:14 <vorlon> aba: hmm, that seems to sidestep the question of which you think we should actually adopt as default :)
18:07:34 <Diziet> bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3420   <- keithp's mail
18:07:57 <aba> vorlon: I'm perhaps just looking from another perspective, and haven't fully finished up yet on the default
18:08:02 <bdale> recent emails suggest the presence of a sentiment that the most important part of what we're deciding on is systemd vs upstart as default for Linux, and that choosing to suggest both should be supported would be considered a non-decision
18:08:13 <vorlon> aba: ok
18:08:34 <Diziet> I'm certainly of the view that we need to support both indefinitely (unless one of them rots totally or something).
18:08:39 <aba> and also, I think we should require packages to support more than one init system, and I also think we should write "support" a bit more than Diziet wrote - basically "main package functionality needs to work"
18:09:02 <rra> Okay, caught up.
18:09:03 <Diziet> aba: That's roughly what I thought I was saying.
18:09:31 <vorlon> bdale: yes, I agree with that sentiment.  Saying "we can have both" leaves us with a divided community, and squanders precious resources
18:09:42 <aba> I think I'd like to have some small changes to your draft on that, but will probably suggest them via the weekend
18:09:47 <Diziet> aba: OK
18:09:47 <rra> I found the recent comments in response to the idea of supporting multiple init systems on an ongoing basis to be interesting.  Usually that sort of suggestion doesn't provoke that negative of a reaction.  I don't think that's a conclusive argument against, but it certainly is cause for concern.
18:09:56 <keithp> Diziet: because of the CLA, I believe that upstart in Debian would be a permanent fork, and take significant resources away from other key development efforts
18:10:13 <aba> keithp: I'm actually not convinced to that.
18:10:15 <bdale> however, there seems to be strong agreement that keeping sysvinit and/or sysvinit+openrc as an alternative for all architectures but particularly for !Linux indefinitely is a good thing
18:10:18 <Diziet> keithp: Debian has been upstream for things the size of upstart multiple times.
18:10:37 <bdale> I know that bothers some strong proponents of both systemd and upstart as a waste of effort
18:10:47 <vorlon> I work on upstart because I want to actually fix problems around the init system; dividing the resources across multiple init systems means we will be less effective at doing this
18:10:51 <Diziet> I don't know enough about sysvinit+openrc to have an opinion about whether it is something I would think worth supporting.
18:11:08 <vorlon> bdale: I wouldn't say that it's a good thing to keep sysvinit/openrc support as an alternative, only that it might be a necessary evil
18:11:10 <Trollinator> aba, may I ask who you are?
18:11:11 <Diziet> But I do think it's important not to consign non-Linux ports to a continuation of the existing buggy racy setup.
18:11:25 <rra> I haven't actually run OpenRC myself.  I did do a bit of reading, although it was hard to find specific docs.  My impression is that it's a clear incremental improvement over standard sysvinit scripts.
18:11:28 <dondelelcaro> Trollinator: /whois is your friend.
18:11:31 <keithp> Diziet: did you watch/read Marc Merlin's LCA presentation on google's migration to Debian?
18:11:42 <Trollinator> dondelelcaro: right, thanks.
18:11:43 <Diziet> keithp: No, I don't do videos as a rule.
18:11:50 <keithp> Diziet: the slides were available
18:12:04 <bdale> Diziet: "consigning" isn't something we get to decide.  non-Linux ports either make the effort to support whatever we pick as a Linux default, or they necessarily have different functionality
18:12:07 <aba> "sysv+openrc" is for me just "either do traditional sysv-scripts, or openrc scripts, either is fine, but you need to do at least one of it"
18:12:13 <aba> which doesn't sound too bad to me
18:12:35 <rra> It's certainly much nicer with OpenRC scripts than traditional init scripts.  The syntax is much improved.
18:12:35 <Diziet> bdale: Um.  If we say they aren't allowed to have upstart then it's sysvinit+bugs, or nothing.  Unless you somehow think that they ought to port systemd.
18:13:14 <rra> I think the single biggest issue with supporting multiple init systems ongoing is testing.  I don't think it's reasonable to expect all Debian contributors maintaining packages with init functionality to test against more than one system.
18:13:27 <aba> Diziet: I think the options are upstart everywhere as default, or systemd+openrc as default
18:13:27 <bdale> it's not clear to me that supporting a useful subset of systemd would be any harder for !Linux systems than supporting a useful subset of upstart, despite what systemd upstream asserts, but I frankly haven't spent a lot of time investigating the details
18:13:37 <vorlon> keithp: I did watch the video; I understand where Marc is coming from (and have had conversations with him about this stuff in the past), but the reality is that for a general-purpose OS on arbitrary hardware (which is the class of problem Debian aims to solve), you don't get a defined order at boot
18:13:40 <Diziet> rra: I agree.  But we don't expect them to test multiple ports either.
18:13:45 <rra> Anthony's message I think points to the right solution there if we can manage it: some sort of buildd-style automated testing for people who aren't running that system.
18:13:51 <Diziet> And most daemons will have a fairly simple setup so I think this is quite tolerable.
18:14:00 <aba> rra: I think ajs Mail to automatic testing is a good idea
18:14:03 <Trollinator> Diziet: there's an effort to make launchd run on FreeBSD...
18:14:17 <rra> Yeah, I generally agree.  For example, I feel fairly confident in my ability to maintain a reasonable init script "blind" for a typical daemon.
18:14:26 <keithp> vorlon: agreed. I think the argument is that Debian should try to support such systems by continuing to offer sysvinit/openrc as an option, but definitely not as the default
18:14:27 <rra> There may be the occasional bug, but it will basically work.
18:14:28 <Diziet> bdale: useful subset> Are you suggesting the Debian/kFreeBSD guys should fork systemd or are you going to overrule the Debian maintainer when they refuse to take the patchset ?
18:15:05 <bdale> Diziet: I don't accept that those are the only two alternatives
18:15:06 <Diziet> Also I would wonder if we could provide some kind of metasyntax for the most common cases at least.
18:15:23 <vorlon> automated testing is always a good idea; OTOH, the last automated testing proposal I saw at DebConf, to have autopkgtests hooked into britney for testing migration, hasn't found anyone willing to work on it, and that's a case where we already have the tests and the jenkins infrastructure
18:15:24 <Mithrandir> Diziet: my position (as the systemd maintainer) is that they should reimplement the stable interfaces.
18:15:27 <aba> Diziet: actually reading our rc bug policy systemd would be RC buggy by not taking a reasonable patch. Which answers that question to me
18:15:28 <Diziet> bdale: Well, err, the Debian maintainers aren't going to take the portability patches and neither are upstream so ... ?
18:15:41 <bdale> but since we'd clearly have to fork upstart for Debian if we choose to use it as default, having to fork systemd doesn't seem a particular blocker
18:15:53 <keithp> Diziet: yes, it would be great if there were a shared daemon management file that could be used by *any* init system.
18:15:58 <aba> Mithrandir: the main question is if it would be possible to have a reasonable patch
18:16:03 <vorlon> bdale: why is it clear that upstart has to be forked?
18:16:09 <rra> The systemd syntax is kind of nice for that purpose as a metasyntax because it's purely declarative.  It's probably easier to go from systemd syntax to upstart syntax than vice versa.
18:16:12 <Diziet> vorlon: He's referring to the CLA.
18:16:18 <bdale> because many of us won't contribute upstream to a CLA'ed project
18:16:19 <keithp> vorlon: because of the CLA. Many developers cannot or will not sign it
18:16:20 <Mithrandir> aba: it wouldn't, unless you reimplement cgroups along the same API on *bsd.
18:16:27 <Diziet> rra: I had precisely the opposite view.  Funny.
18:16:33 <vorlon> my position as Debian maintainer is that I'm open to patches that require a fork, but any work I do as maintainer sidesteps the CLA
18:16:39 <aba> bdale: I'm not sure about forking upstart, and also it's a bit easier IMHO than for systemd
18:16:44 <bdale> so, best case, we call our Debian patches something other than a fork .. I don't see the point in such semantic games
18:16:57 <rra> Diziet: I think that nearly all upstart configurations will require a small bit of shell.  Shell is awful to parse, speaking as a former Lintian maintainer.
18:17:00 <Diziet> The important difference is whether one can still merge from upstream.
18:17:18 <Diziet> The word "fork" used not to mean "make a downstream" until github polluted it...
18:17:49 <vorlon> right, I don't see anything here that warrants the label "fork" to me
18:17:52 <ansgar> Diziet: Net/Free/OpenBSD are also forks IIRC. And they merge from each other.
18:17:57 <keithp> Diziet: the effort required to continue to make merging possible will eventually be larger than the benefit gained by continuing to take upstream changes, I suspect
18:18:00 <vorlon> a downstream isn't a fork
18:18:11 <bdale> the important distinction to me is whether changes made on the "branch" we maintain can ever go upstream .. if not, it's a fork, if so, it's a temporary branch .. not sure that definitional boundary makes sense to everyone, but it's how I think about it
18:18:20 <vorlon> ok
18:18:28 <Diziet> bdale: By that definition practically everything in Debian is already a fork.
18:18:43 <keithp> Diziet: no, in most cases the patches *could* go upstream
18:18:46 <aba> bdale: in that case mgetty is also a fork because I have one trivial patch upstream doesn't like. I don't agree to that.
18:18:49 <bdale> I'm not aware of any of my packages where it's true ..
18:18:52 <Trollinator> rra: are you aware of https://github.com/akhilvij/systemd-to-sysvinit-converter ? It attempts to do what you suggest
18:19:08 <ansgar> Trollinator: It doesn't work.
18:19:13 <rra> Trollinator: Yes, although I'm more interested in ones that convert to either upstart or OpenRC.
18:19:16 <bdale> aba: which is why I suggest that having semantic arguments about this isn't particularly useful
18:19:18 <Diziet> ansgar, Trollinator> Please take that offline.
18:19:37 <Diziet> bdale: The point is that in the case of upstart we could keep merging from upstream indefinitely.
18:19:48 <dondelelcaro> can we refocus? What specifically is our next step?
18:19:56 <Diziet> Also upstart is much smaller so if we do end up unable to merge (ie, forked as I would put it) then maintaining it ourselves won't be a problem.
18:19:57 <aba> dondelelcaro: thanks
18:20:05 <bdale> Diziet: that doesn't differentiate upstart from any other init system choice though, does it?
18:20:06 <vorlon> bdale: not trying to have a semantic argument, but rather to understand what the equivalence is that you see between upstart and systemd; I persist in thinking the scenarios are not equivalent
18:20:11 <dondelelcaro> are we ready to draft voting options now?
18:20:16 <aba> I think we should clarify which options we consider possible
18:20:28 <Diziet> bdale: Yes, it does because the violence you'd have to do to systemd would be huge.
18:20:29 <keithp> aba: agreed
18:20:43 <bdale> Diziet: I accept your opinion on that
18:20:46 <aba> and also if we could finish the "should we support sysvinit+openrc anyways" it might be nice
18:21:20 <keithp> aba: I would like to see us migrate from sysvinit+openrc to just openrc at some point
18:21:29 <Diziet> On the "support multiple" thing, I think my recent email is the best statement of my position.
18:21:37 <Diziet> keithp: I would like to see people _able_ to do so.
18:21:54 <keithp> Diziet: yes, that's what I meant :-)
18:21:59 <aba> keithp: sysv+openrc is "whatever that means in details I don't care for the current discussion" at least for me
18:22:04 <bdale> vorlon: I see systemd and upstart upstream relationships for Debian as having more similarities than differences, but I'm pretty confident that's not a widely held opinion, so I don't know that pursuing it further in discussion here is useful
18:22:17 <rra> Personally, I think that, even if we say we could try to support everything, we're going to naturally converge on at most two systems and the other ones will naturally wither.  I just don't see the project as being willing to expend resources on supporting more than a Linux default and a !Linux default (with the understanding that some folks on Linux will use the !Linux default because they don't like the Linux default).
18:22:20 <Diziet> bdale: They seem radically different to me.
18:22:40 <rra> So we can say "we'll support everything", and it may even be fine to say that, but I think over time we'll find convergence on two options.
18:22:49 <aba> options are IMHO systemd for Linux, openrc for !Linux (default) and everywhere (possible), upstart (default) + openrc, upstart (only), openrc (only or as default) - though I don't think that as useful
18:23:00 <Diziet> rra: The question is: what are you going to say to people who _do_ want to expend their resources on making it work ?
18:23:01 * rra agrees with bdale on the upstream similarities vs. differences.
18:23:03 <keithp> rra: I hope that will become true
18:23:20 <aba> rra: I agree on "maximum two"
18:23:27 <vorlon> rra: agreed; which to me means it's disingenuous for the TC to say that "everything is supported"
18:23:34 <Diziet> I don't think at this stage we can say that any of them has withered.
18:23:53 <Diziet> So at this stage we need to let people do the work they want to do.
18:24:04 <bdale> I agree
18:24:13 <rra> vorlon: Well, we could possibly say that we think we're going to go down to two eventually, but we're not going to pick those two right now.  We're instead going to pick one winner as the Linux default and then we'll see what the project converges on for the other winner
18:24:16 <bdale> which is why I think the most important question before us is choosing the default init system for Linux
18:24:17 <keithp> Diziet: agreed
18:24:36 <rra> That was the point of the wording I was trying to propose.
18:24:39 <aba> Diziet: agree for not refusing one right now, but I don't think we should enforce all three
18:24:41 <bdale> much more so than trying to decide which (set of) alternate init system(s) should be supported
18:24:44 <rra> I would prefer not to tell the !Linux ports which one to converge on.
18:24:49 <Diziet> And at this stage we can't choose the default for !Linux.
18:25:01 <rra> We don't know yet whether OpenRC will work for us for certain, we don't know if upstart will be ported to the Hurd, etc.
18:25:02 <Diziet> Because we don't know what the porting state is of the options.
18:25:08 <keithp> bdale: we definitely shouldn't be kicking packages out of the archive just because they aren't our favorites
18:25:27 <bdale> I agree, I haven't suggested throwing anything out
18:25:33 <aba> I however think a decision there is needed at least within the next whatever months
18:25:40 <dondelelcaro> right; our question is what level of support maintainers are required to give for non-default options
18:25:46 <Diziet> dondelelcaro: Precisely.
18:25:51 <aba> and I also think we should mark packages as RC not supporting any of the default init systems
18:25:54 <bdale> that's the second question, yes
18:26:01 <dondelelcaro> bdale: right
18:26:02 <Diziet> I would say that they should be required to take reasonable patches for all non-default systems that have a suitable section in policy.
18:26:03 <aba> dondelelcaro: and if all the non-default options are the same
18:26:30 <vorlon> rra: well, it's certainly within our remit to say e.g. "if Hurd wants to be releasable it needs to support either the systemd or upstart interfaces"
18:26:34 <aba> Diziet: that's one half, but are they required to support a non-linux-default so that the daemon works anyways?
18:26:39 <bdale> aba: that won't be true, though, unless we tell either systemd or upstart to pound sand
18:26:56 <Diziet> aba: You mean that a package X which fails to support init system I where I is one of the defaults is RC even though X may support some I' which is another default ?
18:26:57 <aba> bdale: sorry, I don't understand your last three words
18:26:58 <vorlon> that doesn't address the question of whether openrc will be usable however, since it's too early to tell
18:27:16 <bdale> aba: sorry, unless we tell one of them to completely go away
18:28:13 <aba> Diziet: if we have default L for Linux-Systems and default K for non-Linux, then I think we should require all packages to support both. Whatever L and K are.
18:28:14 <bdale> Diziet: I think there can be only one "default" for a given architecture
18:28:25 <rra> vorlon: I suppose, but meh.  I have a hard time justifying that if we're going to require support for sysvinit scripts for jessie anyway.
18:28:36 <Diziet> I think we are all agreed that in jessie sysvinit support is still mandatory.  So in principle something which supported only sysvinit would be releasable.
18:28:39 <keithp> vorlon: I hope openrc is able to essentially take-over for sysvinit; it offers the same semantics with a slightly nicer interface
18:28:48 <Diziet> aba: Right.
18:28:48 <vorlon> rra: I think the justification is in not having to support init scripts for jessie+1
18:28:58 <vorlon> which requires some forward planning
18:29:01 <aba> Diziet: for jessie, yes. But I wouldn't limit the "needs to support all default init systems" to jessie
18:29:11 <bdale> aba: I agree in theory, but since the wheezy kfreebsd releases were technology previews and it's not yet clear that they'll meet the jessie release criteria as fully supported architectures, and hurd has never been a released architecture, I don't know how hard we should worry about it?
18:29:18 <Diziet> aba: Right.
18:29:22 <rra> vorlon: My point is that by the time we start seriously planning for jessie+1, a bunch of these porting issues will probably have resolved.  For example, we may have a working upstart port everywhere, OpenRC will have been pounded on much more, etc.
18:29:29 <Diziet> We are going to have to have this conversation again in jessie+1.
18:29:36 <rra> So we're to some extent borrowing trouble by trying to pick a winner for !Linux right now.
18:29:58 <aba> bdale: I think kbsd is stable enough, but of course the release team could reduce the set of default init system over all architectures easily
18:30:11 <bdale> so, it seems to me that at least for the jessie time frame, we must continue to support sysvinit .. is there any disagreement on that?
18:30:24 <rra> bdale: There's some disagreement over exactly what that means.
18:30:27 <vorlon> rra: well, I see it very differently; I am disappointed in the TC's reluctance to decide on a direction for the project (and not just because I have one preferred direction I'd like the project to go in)
18:30:35 <Diziet> Given that the existing systems all support sysvinit scripts, a package can be non-rc buggy simply by supporting init scripts.  In jessie that's going to be required anyway.  So there is no decision to be made at this stage about what set of init systems must be supported by packages.
18:30:44 <aba> bdale: the word "Support" might be read different by different people
18:31:05 <rra> bdale: In particular, whether that means a desktop environment cannot require logind.
18:31:10 <vorlon> I think we are wasting a lot of maintainer energy futzing around with 4 different init systems, that would be put to better use if we had a clear direction
18:31:25 <keithp> Diziet: I would say that a package would be rc-buggy if it didn't support the default init system on each platform
18:31:26 <aba> Diziet: I disagree because that is setting expectations and plannings. But as you said, simple init scripts for sure work everywhere
18:31:32 <Diziet> rra: I think it means that a desktop environment cannot require that a particular thing is pid 1.
18:31:37 <bdale> keithp: I agree
18:31:47 <Diziet> aba: OK, so I agree with you about planning.
18:31:56 <bdale> where "each platform" is each architecture slated for the next stable release
18:32:01 <keithp> Diziet: which means, that if upstart or systemd is the default on Linux, then every package would need to support them
18:32:04 <aba> bdale: yes
18:32:09 <rra> Diziet: We probably need to provide guidance as to how to express a hard dependency on a "working logind", then.
18:32:28 <Diziet> What I would like to say about planning is: we hope that the default can be upstart on !Linux (at least) and that packages must in jessie+1 must support both upstart and systemd.
18:32:29 <aba> rra: good question.
18:32:33 <bdale> to the extent that 'support' systemd or upstart could mean via the existing init scripts, right?
18:32:54 <aba> bdale: if the existing init scripts continue to provide a useable daemon
18:32:55 <keithp> bdale: I would like to be able to say 'no', and that 'support' really meant integrating into the native system
18:32:56 <Diziet> rra: Surely the desktop maintainers can work that out ?
18:33:19 <rra> Do we really want to pick upstart for, say, kFreeBSD, rather than let the kFreeBSD porters decide whether they prefer OpenRC to upstart?
18:33:23 <vorlon> rra: I don't understand why logind is a concern.  There are integration issues with the way it's currently packaged, and there's the matter of cgroup handling in systemd v205 that needs to be addressed to make logind 205 compatible with !systemd, but Mithrandir and I seem to have an agreement regarding the former, and the latter is something that's being sorted out in Ubuntu now
18:33:28 <keithp> At least where the upstream project has native support
18:33:29 <Diziet> bdale: Yes, but in jessie+1 maintainers can drop the sysvinit script iff they have all the defaults.
18:33:39 <ansgar> keithp: You want to make not supporting Upstart/systemd (if they become default) RC for jessie?
18:34:26 <Diziet> I think native non-forking startup support for both upstart and systemd should be release goals.
18:34:30 <rra> vorlon: Because I'm unwilling to assume that's all just going to magically work for jessie.  If it does, great.  But I think desktop environments need a way of expressing a dependency on a working logind right now.  The only current mechanism available to them is to require systemd as process 1.
18:34:35 <Diziet> (By which I mean they should have a low nmu threshold etc.)
18:34:41 <keithp> ansgar: I would like that to be possible where the upstream package has native support, yes, but I doubt it's practical :-)
18:34:42 <bdale> Diziet: I'm pretty sure if we try to assert a requirement for supporting both upstart and systemd that a GR will follow
18:34:45 <Diziet> But the lack shouldn't cause packages to be thrown out.
18:34:49 <aba> rra: I'd only pick upstart for kbsd provided we decide upstart for linux and upstart works on kbsd
18:35:07 <bdale> Diziet: because I'm pretty sure that will be interpreted as a failure to make a decision
18:35:08 <Diziet> bdale: I'm not concerned about any GR.
18:35:08 <rra> aba: Yes, that's my inclination as well.
18:35:18 <vorlon> rra: if the kfreebsd porters decide they like openrc, and the hurd porters decide they like upstart, what then?  If we think one is better than the other, we should say so now
18:35:36 <aba> Diziet: I think we should have "provide available init systems" as release goals anyways.
18:35:41 <Diziet> vorlon: I agree and upstart is at least more ready than openrc and probably better.
18:35:44 <vorlon> rra: process 1> absolutely not true.  A dependency on systemd, systemd-shim | systemd-sysv provides this guarantee, without requiring systemd as pid 1
18:36:37 <rra> vorlon: You mean logind, systemd-shim | systemd-sysv?
18:36:40 <vorlon> rra: that works, right now.  It will not work, if the systemd maintainers rev to v205; but that's a distro integration issue that we need to address regardless if we expect upgrades from wheezy to jessie to work cleanly
18:36:41 <ansgar> vorlon: systemd-sysv is not recommended to be used.
18:37:28 <vorlon> rra: presently, logind is packaged in the systemd binary package.  Splitting it out is the thing Mithrandir and I need to discuss in finer detail yet (with patches and comaintainers). :)
18:37:31 * rra tries to understand exactly what systemd-shim provides, since it doesn't depend on anything else.  Are you saying that systemd-shim contains a complete working logind?
18:37:44 <rra> Otherwise, I see no way that dependency would guarantee logind is available.
18:38:00 <vorlon> rra: systemd-shim provides the dbus interfaces that, on a systemd system, are provided by pid 1; it satisfies the dependencies for logind itself
18:38:05 <Diziet> I don't think this discussion of implementation details of how to make this work is particularly relevant here, is it ?
18:38:20 <aba> are there some decisions we could take down from above?
18:38:29 <Diziet> aba: It's tricky.
18:38:32 <bdale> not that I can discern
18:38:52 <vorlon> Diziet: well, maybe this isn't the best place for it, but I've seen oft-repeated claims on the bug that "we have no choice but to take systemd as PID1 because the desktops require it", and that's provably false
18:39:01 <bdale> I see two questions facing us immediately
18:39:02 <rra> vorlon: Oh, so the dependency is actually "systemd, systemd-shim | systemd-sysv"?  I think I understand.
18:39:08 <vorlon> rra: yep
18:39:13 <bdale> one is what the default init system for Linux should be for jessie
18:39:13 <aba> I think the "decide on upstart as default for kbsd provided we decide upstart for linux and upstart works on kbsd" was consensus?
18:39:14 <Diziet> vorlon: Presumably no-one is saying that here so let us not discuss it.
18:39:36 <rra> Diziet: I found the discussion helpful because I didn't entirely understand what systemd-shim was doing.
18:39:41 <bdale> the other is to what extent we believe package maintainers should accept patches and/or provide other forms of support for alternate init systems in the jessie time frame
18:39:42 <Diziet> aba: Well, should we decide something different for openbsd ?
18:39:46 <Diziet> Err, um
18:39:49 <Diziet> I mean freebsd
18:39:54 <Diziet> (Where did openbsd come from??)
18:40:04 <aba> Diziet: let the porters decide?
18:40:22 <rra> bdale: Agreed.
18:40:43 <bdale> for question one, the default init system for Linux for jessie, we seem to have three alternatives
18:40:49 <aba> bdale: and the second splits up into "what do we require maintainers to activly do" and "what do they need to accept"
18:40:50 <Diziet> So is there anyone who is suggesting that support for at least upstart and systemd shouldn't be release goals ?
18:40:51 <bdale> systemd, upstart, sysvinit
18:41:12 <bdale> Diziet: and or or?
18:41:36 <Diziet> Two release goals: native support for {upstart,systemd}
18:41:43 <vorlon> Diziet: I think the question of release goals is subordinate to the question of default for the non-Linux ports
18:41:52 <aba> bdale: I already think we dropped openrc as default last time
18:41:53 <keithp> vorlon: agreed
18:41:54 <Mithrandir> I don
18:41:56 <Mithrandir> argh
18:42:03 <Mithrandir> I don't think both of them should be release goals.
18:42:06 <Diziet> vorlon: You think we shouldn't have a release goal for non-default systems ?
18:42:15 <Mithrandir> pick one, whatever you choose as the default.
18:42:24 <dondelelcaro> Diziet: yes, whatever isn't the default should not be RC.
18:42:31 <Diziet> But if we choose upstart as default on kfreebsd then that _is_ a default.
18:42:32 <aba> well, release goal := maintainers should accept patches
18:42:34 <Mithrandir> (release goals are not RC)
18:42:48 <Diziet> aba: No, it means something strong.
18:42:49 <aba> dondelelcaro: release goal = maintainers should accept patches. it doesn't mean missing support is RC
18:42:52 <Diziet> stronger
18:43:01 <Diziet> Maintainers should accept patches anyway.
18:43:11 <vorlon> Diziet: if Debian says "systemd on Linux, OpenRC on !Linux", then I'm not going to spend my time on writing upstart jobs for Debian, I'm going to spend it making systemd integration work in Debain
18:43:12 <bdale> Diziet: on what basis could we choose a default for kfreebsd today?  I'm glad upstart is sort of working there, but it sure doesn't sound ready for release yet.
18:43:13 <aba> Diziet: people could NMU it, right.
18:43:26 <rra> Supporting Hurd has not been at the level of a release goal in the past, just a normal bug.  kFreeBSD reached a higher level as a technology preview, which I suppose is roughly equivalent.
18:43:28 <Diziet> aba: Right.  RG means NMU
18:43:42 <vorlon> Diziet: and I wouldn't support suggesting different priorities for people other than myself
18:43:47 <Diziet> bdale: I'm sure it can be made ready.
18:44:06 <Diziet> vorlon: I'm not suggesting that anyone be mandated to do any work.
18:44:09 <dondelelcaro> Diziet: maybe, but until it's ready, we can't decide it
18:44:24 <Maulkin> .oO( Random thought - !linux aren't release arches at the moment. I would suggest not calling things RC if you mean severity grave, to avoid confusion)
18:44:27 <vorlon> Diziet: no, but calling it a release goal is suggesting a priority
18:44:28 <Diziet> At the moment I'm asking what people who _do_ want to do the work are allowed to do.
18:44:28 * rra apparently has a much higher future discount rate for volunteer technology projects than other people in this discussion.  :)
18:44:28 <aba> bdale: if we decide for upstat for linux, I'm quite sure upstart will be ready on kbsd. But of course the decision should contain some "if upstart is ready, ..."
18:45:03 <vorlon> frankly, I think there's a very large gap between how the init system maintainers (at least, upstart and systemd) are viewing this decision, and how a number of members of the TC are viewing it
18:45:27 <vorlon> I'm hearing from various TC members the idea that we just need to pick a default, and we can "let the market decide" how well supported the non-default will be
18:45:42 <Diziet> vorlon: That's how we normally make decisions.
18:45:53 <vorlon> whereas I, and I think Mithrandir as well, view the TC decision as the end game
18:45:57 <Diziet> We the Debian project.  We don't stand in the way of people wanting to do work.
18:45:57 <aba> vorlon: I think that's only true for the options 3/4
18:46:26 <bdale> vorlon: it's ok for you to view it that way, but that's not how Debian works
18:46:27 <vorlon> Diziet: but the TC is deceiving itself if they believe that the decision does not have explicit consequences for the work people will choose to do
18:46:32 <Mithrandir> vorlon: thank you; very much agreed.  Pick one, I'm hoping it'll be what I want, likewise for you, but it's actually not the end of the world if we end up with the "wrong" solution.
18:46:37 <aba> I'm happy to have the market decide how good the "other non-default options" are supported, but no the options we need for linux and kbsd.
18:46:40 * rra wanrs that I have a mandatory work meeting in 13 minutes that I unfortunately can't be late for.
18:47:05 <aba> (and I don't expect any non-enforced options to be properly supported BTW)
18:47:13 <Diziet> aba: WDYM by "enforced" ?
18:47:17 <bdale> I'm *sure* that whatever decision we make on a default will impact motivations both pro and con, but that doesn't mean that I think not choosing something as default should be implied as meaning I think nobody should work on it if they want to
18:47:18 <aba> Diziet: RC bugs
18:47:31 <Diziet> Are you suggesting RC bugs for non-native-support ?
18:47:34 <Diziet> Or just for non-support-at-all ?
18:47:36 <vorlon> bdale: but we were talking about release goals
18:47:55 <Diziet> We have multiple levels of "enforcement": RC, release goal, maintainers must accept patches, maintainers can say FOAD.
18:48:02 <aba> I'm happy with people supporting the other init system by NMUs etc, but I don't have much expectations
18:48:05 <keithp> vorlon: as a release goal, we should encourage the best support possible for the default init system across the board
18:48:10 <vorlon> and I think passing a resolution saying support for the non-default init system is a release goal, *knowing* that the maintainer of that init system has no interest in driving it, is preposterous
18:48:11 <rra> Right, there's a difference between "you chose not to work on this because it's not the default" and "you're not allowed to work on this effectively any more."  The latter would, IMO, be rude, and I don't want to say that.
18:48:12 <Diziet> And we have multiple levels of "support": native, non-native via sysvinit, perhaps some compat scheme that doesn't exist yet.
18:48:23 <keithp> vorlon: and as an explicit non-goal, support for init systems which are *not* the default anywhere
18:48:40 * rra agrees with keithp.
18:48:59 <rra> The most important thing for Debian in terms of project goals going forward will be strong, integrated support for the default init system, whatever that is.
18:49:00 <Diziet> vorlon: If you don't want to be the maintainer any more if it doesn't get to be the default then that's up to you.
18:49:01 <vorlon> rra, keithp: right, I'm speaking specifically to the point of release goals, not suggesting that the TC should say that the non-default must not be supported
18:49:20 <Diziet> "release goal" means people are allowed to NMU
18:49:21 <aba> rra: make that plural please (init systems)
18:49:27 <Diziet> That's pretty much the only thing it means.
18:49:45 <keithp> aba: default is going to be per-kernel, that much seems clear
18:49:45 <aba> I think I'm happy with that, but I don't think that is the main point of the decision
18:49:52 <vorlon> Diziet: the standing NMU policy means people are allowed to NMU anyway; calling it a "release goal" is a sort of imprimatur
18:49:55 <aba> keithp: yes
18:50:08 <Diziet> vorlon: I mean 0-day.
18:50:08 <vorlon> and I don't think that imprimatur is appropriate, for a non-default init system
18:50:13 <rra> aba: I'm not certain that we really can.  I'm a big supporter of the !Linux ports, but I think we also have to be realistic about the fact that they're not what most of the Debian contributors care the most about.  I want to make them possible, but I don't think they're at the center of the project's future goals (nor do I think the porters working on them believe that they are).
18:50:45 <vorlon> Diziet: ok.  if we were to say "relaxed NMU policy", I could get behind that
18:50:50 <Diziet> vorlon: Right.
18:50:51 <bdale> right.  that's why job one here must be choosing the default for Linux
18:50:52 <Diziet> That's what I care about.
18:50:55 <aba> rra: I don't think the ports are, but the fact that we could actually have different init systems and different kernels are relevant IMHO
18:50:59 <vorlon> I just don't want to say "release goal", because that implies it's a *goal*
18:51:04 <rra> In other words, I want to make support for !Linux ports possible, but I think we should focus on making sure that the default init system on Linux works as well as we can make it.
18:51:17 <Diziet> rra: Who is "we" ?
18:51:35 <rra> Diziet: The project as a whole to the extent that we set project direction via such things as RC bug policy and release goals.
18:51:43 <aba> rra: I didn't think anyone suggested to make a wrong selection for the linux ports
18:52:35 <rra> aba: Yeah, I know.  The problem with talking about this is that it's a suble prioritization issue, and it's easy to make it sound like I'm rejecting something I'm not rejecting.
18:52:39 <Diziet> I would like to propose that we cut short the substantive discussion now and go onto next steps.
18:52:59 <aba> Diziet: yes
18:53:01 <keithp> Diziet: given that we have 6 minutes until the top of the hour, yes
18:53:08 <Diziet> It looks like the arguments are about the exact level of support/requirement for various things.
18:53:26 <rra> yeah, and that's also where Diziet and I got bogged down in wording on the voting options.
18:53:31 <Diziet> Some of us have already made clear statements about the level of support we want to see for each thing.
18:53:52 <Diziet> I would appreciate it if the rest of you would take some time to answer questions like:
18:53:57 <aba> I think we should write down what we learned from this discussion (or at least I should)
18:54:05 <Diziet> * Should native support for the non-default systems have a low nmu threshold ?#
18:54:40 <Diziet> * What direction do we give for jessie+1 - are we hoping for two systems (which two), or more, or are we not saying ?
18:55:08 <Diziet> * What should be an RC bug in jessie+1 ?
18:55:19 <ansgar> Diziet: Two init systems on Linux or across all ports?
18:55:24 <Diziet> * What should be an RC bug in jessie ?
18:55:31 * rra concurs with Diziet's questions.
18:55:47 <Diziet> * What direction hints do we want to give, if any, re non-Linux ports at this stage ?
18:55:54 <bdale> I will assert that I'm substantially less comfortable including explicit jessie+1 language in any decision made at this time than I am in asserting decisions for jessie
18:55:54 <aba> btw, I think we need to have our meeting in 2 weeks
18:56:24 <Diziet> Also can I ask people to reply by email as I don't want to try to figure stuff out from this irc scrool.
18:56:27 <aba> bdale: I would put anything for jessie+1 as default options, i.e. unless release team / policy maintainers decide otherwise
18:56:36 <aba> Diziet: that'd be welcome
18:56:49 <Mithrandir> it's not clear you're allowed to make a decision about what should be RC bugs, btw.  §6.3.6.  -release makes that decision.
18:56:50 <keithp> Diziet: please send that out via email so we can reply then; keep everything together in one place
18:56:52 <Diziet> Finally I would like a quick deadline for final answers.
18:56:57 <Diziet> keithp: Willdo.
18:56:57 <rra> I also have open concerns about post-205 systemd and logind and the implications of that for jessie.
18:57:09 <bdale> dondelelcaro asserted that he can post something by Fri, I think?
18:57:13 <dondelelcaro> #action everyone to answer diziet's questions
18:57:16 <dondelelcaro> bdale: yes.
18:57:23 <bdale> aba, do you intend to post some summary of your opinions?
18:57:24 <Diziet> By when ?  End of the weekend ?
18:57:36 <aba> bdale: yes, probably by end of weekend
18:57:41 <Diziet> OK then.
18:57:42 * bdale just read keithp's email, thanks for that
18:57:49 <Diziet> Right.
18:58:09 <bdale> so, Diziet, how about putting your question list in an email?
18:58:15 <aba> last question: do we meet in 14 days again?
18:58:35 <bdale> then I'd hope that by end of the coming weekend we can all finish posting base opinions *and* answer your question set.  reasonable?
18:58:44 <rra> That's good here.
18:58:50 <keithp> good for me
18:58:51 <bdale> aba: I agree that another meeting in 14 days seems prudent
18:58:55 <rra> and I have to go, sadly.  See you all later!
18:58:58 <Diziet> bdale: Yes, going to do that.
18:59:05 <aba> sounds good
18:59:13 <bdale> ok
18:59:16 <aba> and thanks for the meeting.
18:59:28 <bdale> so if we can all do those things by end of the weekend, then next week we can try to get a draft ballot done?
18:59:42 <vorlon> sounds good
18:59:47 <keithp> bdale: has someone volunteered to write the draft?
18:59:48 <vorlon> btw
18:59:52 <vorlon> are people still using their VMs?
19:00:02 <bdale> Diziet has a draft for the pro-upstart option, I think
19:00:03 <keithp> vorlon: no, I'm done with mine
19:00:05 <aba> vorlon: if you could let mine survive till monday it would be nice
19:00:06 <dondelelcaro> vorlon: I'm not
19:00:08 <vorlon> (I'd like to start shutting them down once people no longer need them, but I don't want to rush anyone)
19:00:09 <bdale> and has offered to help draft other options
19:00:14 <vorlon> keithp: ack, thanks
19:00:22 <keithp> vorlon: thanks again, was much helpful
19:00:23 <bdale> vorlon: I'm done with the VMs .. thanks
19:00:26 <aba> I currently assume we will have some more discussions after the weekened
19:00:40 <Diziet> I'm happy to continue with the drafting unless people think I'm doing it wrong.
19:00:44 <weasel> I wondered.  Will my package have to provide the same functionality using the default/standard init system, or can I make it support more/great things only with systemd/upstart/weaselinit in use?
19:00:58 <Diziet> vorlon: Yes, please kill those VMs.
19:01:03 <dondelelcaro> I think we can continue drafting via git in the repository; if someone wants to take the lead, that would be fine
19:01:21 <dondelelcaro> ok; is there anything last minute to discuss here?
19:01:30 <dondelelcaro> #topic Additional Business
19:01:38 <aba> weasel: I'd tend to say "things that are reasonable possible via default need to be supported there"
19:01:55 <aba> dondelelcaro: none for me, as we meet again in 14 days I think
19:02:30 <bdale> dondelelcaro: yeah, let's go ahead and meet on the 30th, and plan to have that meeting *focus* on our other non-init-system issues
19:02:31 <dondelelcaro> #endmeeting