--- /dev/null
+19:00:20 <marga> #startmeeting
+19:00:20 <MeetBot> Meeting started Wed Mar 20 19:00:20 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
+19:00:20 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+19:00:29 <marga> #topic Roll Call
+19:00:33 <marga> Who's here for the meeting?
+19:00:38 <Mithrandir> Tollef Fog Heen
+19:00:39 <marga> Margarita Manterola
+19:01:02 <ntyni> Niko Tyni
+19:01:03 <OdyX> OdyX
+19:01:06 <OdyX> Didier Raboud
+19:01:17 <OdyX> eh, long day…
+19:01:19 <gwolf> Gunnar Wolf
+19:01:25 <bremner> David Bremner
+19:02:50 <marga> We are missing a fil and smcv apparently
+19:02:57 <marga> Let's move to the next topic
+19:03:12 <marga> #topic Review of previous meeting AIs
+19:03:32 <marga> http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-02-20-18.58.html is the summary of the previous meeting
+19:03:57 <OdyX> Well. We closed #914897, which was… hard.
+19:04:01 <marga> Yeah
+19:04:04 <marga> Agreed :)
+19:04:19 <marga> But we did it. Good job everybody. Next time please let's not have a tie :)
+19:04:24 <OdyX> and you closed #911225; which makes two in a month.
+19:04:33 <gwolf> (-:
+19:04:36 <Mithrandir> yeah, apologies for failing to vote on 914897. :-/
+19:04:53 <OdyX> I failed to ping you too. Sorry for that.
+19:04:58 <marga> And gwolf closed #919951, so it's actually three in a month.
+19:05:08 <OdyX> oohh
+19:05:13 <marga> However, we still failed to make progress on the maint-scripts issue :-/
+19:05:34 <marga> Which is actually the next topic, so let's move to that.
+19:05:45 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
+19:06:01 <OdyX> I have two very draft mails pending for months, but it imposes me to take a half day to re-read all this and think about it.
+19:06:20 <marga> two drafts about maintscripts?
+19:06:40 <OdyX> nah, just to answers to various points.
+19:07:34 <OdyX> So don't expect much progress.
+19:08:30 <marga> Ok. I'm a bit surprised at my lack of progress in this matter, given that this is something that I certainly care deeply about.
+19:08:35 <bremner> are we deadlocked between well defined positions?
+19:08:44 <marga> I suspect that I fail to find the time for it because I'm afraid of people being against me.
+19:09:04 <marga> I don't think the positions are very well defined, no.
+19:09:05 <OdyX> bremner: That's not my understanding no.
+19:09:16 <bremner> just checking for the easy case ;)
+19:10:09 <OdyX> he he
+19:10:38 <Mithrandir> we've spent a lot of time debating it here before, can we look for process improvements instead of going into the matter of the discussion?
+19:11:03 <marga> Like what?
+19:11:15 <gwolf> marga: It's a hard-ish mail to write, so don't take it bad on yourself. Or ask for help.
+19:11:22 <gwolf> As you prefer.
+19:12:07 <marga> Yeah, I did ask for help, and we had said with fil that we would collaborate on this, but that didn't happen :-/
+19:12:40 <Mithrandir> marga: I don't know offhand, but since the current process frustrates us, try to think of another angle of approach.
+19:13:07 <gwolf> marga: oh :( Sorry, I've been too busy to really pay attention (or to offer my help!)
+19:15:11 <marga> So, I think the problem that we have is that the main issue here is a design problem, and we are supposed to not do design work
+19:15:40 <Mithrandir> so who is it that does this kind of design work, then?
+19:15:59 <marga> Nobody?
+19:16:07 <marga> I mean a random developer that feels like doing it, maybe
+19:16:08 <bremner> also, we were asked, no?
+19:16:09 <Mithrandir> or does it mean Somebody™ does it outside of the TC, but we don't do it inside the bug log?
+19:16:25 <marga> And then they somehow they need to convince the project that it's a good idea
+19:16:46 <OdyX> My understanding and practice of that constitution article is that we shall not be doing design work "as the TC"
+19:17:03 <bremner> I thought we went through the meta / constitutional issues and it was OK?
+19:17:06 <marga> bremner, we were asked about one thing (whether maintscripts should fail in a specific circumstance), but that led to us realizing that the problem is the whole workflow, not that single circumstance
+19:17:36 <bremner> oh, the request was specific to restarting services?
+19:17:49 <OdyX> We could stick to answering the question, and spawn a non-TC design group/process.
+19:17:54 <marga> Yes
+19:18:02 <marga> How would we do that?
+19:18:30 <bremner> volunteer? send a mail to dda asking for people to join?
+19:18:41 <gwolf> Right, makes sense to say "it's not what the TC can do, but we can help create the right group for that"...
+19:20:49 <Mithrandir> wfm
+19:21:06 <marga> But what do we do about the thing we were asked to rule on, then?
+19:21:53 <Mithrandir> wait for the recommendation from the working group?
+19:21:55 <gwolf> "The TC decides the problem it was asked to rule upon falls outside its boundaries of constitutional action"?
+19:22:11 <OdyX> say "it's too undefined to break a tie, but we're interested to draft something"
+19:22:56 <Mithrandir> gwolf: nah, we can rule on it, we just need to have some detailed designs to choose from
+19:23:13 <gwolf> Right, Mithrandir makes sense
+19:23:18 <gwolf> from a Special Designed Task Force!
+19:24:22 <marga> Ok, so the plan is: recommend that a group is formed to work on a better solution to communicate failures to the user than failing maintscripts. This group should present proposals and then the TC rules on which proposal to implement?
+19:24:53 <OdyX> or proposes on -devel and we only chime if the consensus isn't attainable.
+19:25:17 <bremner> so is this a case where we make policy ahead of practice?
+19:25:57 <Mithrandir> practice is a bit all over the field, iirc?
+19:26:04 <OdyX> that's my point: start by proposing something, convince the community, rule if no consensus?
+19:26:15 <marga> Yeah, and the problem is that there is no better mechanism for communicating with the user
+19:26:22 <marga> That's what the working group needs to deal with
+19:26:28 <gwolf> Right - but we can help steer policy to an incipient but not yet established practice? :)
+19:26:33 <marga> Find a better communication channel than a failing maintscript
+19:27:28 <bremner> OK. Let's say the decision comes back to us if necessary, but not necessarily?
+19:28:10 <gwolf> yes. I like that.
+19:28:11 <marga> Yeah, that would make sense to me.
+19:28:19 <gwolf> Maybe the best decision will naturally emerge
+19:28:52 <Mithrandir> we're happy to bless something if that makes sense and makes it carry extra weight, though
+19:29:09 <Mithrandir> so we don't end up with two competing implementations of slightly-incompatible ideas.
+19:30:04 <ntyni> the original question was "does the T.C. think that Debian can be consistent on service (re)starts in maintscripts, or is the best we can do to leave it up to package maintainer discretion?"
+19:30:11 <ntyni> so we could say "Debian cannot be consistent with current infrastructure but we recommend developing the infrastructure" ?
+19:30:39 <marga> I like that, yes.
+19:30:42 <marga> Strongly recommend
+19:30:53 <Mithrandir> ok
+19:31:03 <gwolf> ntyni: excelent reading/answer
+19:31:12 <bremner> or at least we can't reach concensus on what should be the consistent behaviour
+19:32:21 <marga> Ok, do we need to vote on this? It seems we all basically agree
+19:32:57 <bremner> since it's sortof a non-ruling, I guess we could just reply to the bug, maybe even leave it open?
+19:33:53 <marga> Ok. I'll take the AI, I think I have a clear path forward
+19:34:00 <OdyX> yay
+19:34:08 <gwolf> Well, we managed not to find a way out already. I think this is the right path
+19:34:17 <gwolf> I mean, would be nice to have all of us say "this is right"
+19:34:28 <gwolf> but I don't see any dissent. So in the worst case we have a majority
+19:34:55 <marga> #action marga to send mail to the bug saying that: Debian cannot be consistent with current infrastructure but we recommend developing the infrastructure that would allow consistency, by forming a working group.
+19:35:14 <ntyni> wfm fwiw
+19:35:25 <marga> Alright, let's move to the item that didn't make it to the list originally.
+19:35:30 <bremner> we should specifically encourage people interested in non-systemd inits to participate
+19:35:37 <marga> #topic #923450 Requirements for being pre-dependency of bin:init
+19:35:40 <bremner> (in the working group)
+19:36:11 <marga> So, I just saw this earlier today, when I was checking the TC open bugs and it turned out that this mail had been rejected by bendel, so I forwarded it to the list
+19:36:48 <OdyX> Hrm. Out of reading this right now, I don't see myself agreeing with the submitter.
+19:36:51 <gwolf> I haven't yet checked it even
+19:36:59 <Mithrandir> I haven't read this either
+19:37:17 <OdyX> (it's short, go ahead now :-) )
+19:37:22 <bremner> I think the submitter has probably behaved inappropriately. I'm not sure that's our domain.
+19:37:23 <ansgar> "init" isn't essential.
+19:37:34 <marga> The issue here is that the maintainers of init-system-helpers were not agreeing to put runit-init as one of the alternative pre-depends of the init meta-package
+19:37:55 <gwolf> (heh, the bug even has a nice number 😉)
+19:38:00 <ansgar> (Though apt will complain loudly when asked to remove "init" similar to how it complains for essential packages)
+19:38:21 <marga> There's been an NMU for init-system-helpers by Dmitry Bogatov that includes the Pre-Depends in December and it hasn't been overridden.
+19:38:33 <OdyX> (it was nmu'ed by KAction, the TC bug submitter)
+19:38:34 <bremner> it was NACKed though
+19:38:41 <OdyX> well, it's in the archive.
+19:38:52 <marga> Yeah, but it was allowed to stay and get into the buster release...
+19:38:57 <bremner> yes, that's the part I consider behaving badly
+19:38:59 <bremner> ymmv
+19:39:00 <gwolf> Uff, I think having "init-system" as a virtual package... could bring issues, to say the least...
+19:39:21 <marga> Yeah, I have no idea how many things would break
+19:39:47 <marga> But in any case, I think the question is valid. Why are the maintainers of init-system-helpers the gate-keepers of alternative init systems?
+19:39:58 <ansgar> marga: They aren't.
+19:40:07 <OdyX> On the other hand, why not?
+19:40:13 <gwolf> I am multitasking too heavily right now and cannot really comment on this...
+19:41:05 <ansgar> I actually think it would be better it the "Important: yes" bit that "init" has was moved to "systemd-sysv" and similar packages. Especially should someone decide to /not/ keep service state in sync between different init providers.
+19:42:28 <Mithrandir> the question as phrased looks like detailed design, though
+19:42:36 <marga> The thing that confuses me is that I expected the list of pre-depends to include upstart and openrc, but it only includes systemd-sysv, sysvinit-core and runit-init
+19:42:58 <ansgar> marga: OpenRC does not provide /sbin/init. Upstart is dead.
+19:44:19 <OdyX> As things stand, it seems that enforcing a set of interfaces as "provided" by bin:init makes sense.
+19:45:47 <ntyni> so aiui maintainers of init-system-helpers are currently gatekeepers for getting your own init package installable without having to answer the "do as I say!" prompt
+19:46:01 <ntyni> and it doesn't seem unreasonable to me to ask for some set of rules for that
+19:46:22 <Mithrandir> I agree it should be a defined set of criteria, but I also think Dmitry is behaving rudely by refusing to cancel the NMU and pulling out the TC hammer quite early on, so there are social issues at play as well.
+19:46:26 <gwolf> People, I must leave at once... Sorry :(
+19:46:34 <Mithrandir> gwolf: see you around
+19:46:43 <gwolf> o/ !
+19:46:50 <OdyX> From reading #838480, it seems that they gatekept with scrutiny and care.
+19:46:52 <ntyni> (agreed on the inappropriateness of the NMU)
+19:46:55 <Mithrandir> ntyni: yeah, or other workarounds when installing the system.
+19:46:56 <ansgar> ntyni: Well, installable in systems that already have init installed and where the alternative conflicts with init.
+19:47:44 <ntyni> OdyX: yes, I also think they seem to be doing a good job about it
+19:48:11 <Mithrandir> I'm probably slightly biased since I used to maintain systemd and have worked closely with some of the current maintainers for a long time, but my impression is that the engineering done by the systemd team is not biased and the criteria used are carefully chosen.
+19:48:26 <Mithrandir> (Even if not expressly enumerated)
+19:48:47 <ansgar> As long as the NMU doesn't get reverted, is there a real problem?
+19:49:00 <bremner> even if the maintainers are doing a bad job, we have procedures for overriding maintainers, and NMU is not it
+19:49:19 <bremner> I guess I'm some kindof "maintainer fundamentalist" here.
+19:49:25 <OdyX> not really no. And I really don't like setting rules for non-problems.
+19:49:34 <Mithrandir> ansgar: yes, there are social bits here, and it's a bad precedent, and it means we still don't have clear criteria.
+19:50:07 <marga> A clear criteria for what exactly?
+19:50:09 <bremner> Mithrandir: are the social problems our problems?
+19:50:29 <Mithrandir> marga: for what warrants inclusion as an alternative init system
+19:50:42 <ansgar> Mithrandir: What should tech-ctte do with social problems? Ask the maintainer to revert the NMU? Ask the maintainer to accept the NMU (even though it wasn't reverted so far)?
+19:50:43 <marga> I thought you just said above that the criteria used are carefully chosen?
+19:50:58 <OdyX> I'd wouldn't want to go much further than recommending that the bin:init maintainers specify/document their requirements.
+19:51:02 <Mithrandir> marga: but they're not expressed clearly.
+19:51:44 <Mithrandir> bremner: hmm. I think they maybe are, since the entire package landed at our doorstep?
+19:52:30 <OdyX> well. The NMUer complains to the TC that they cannot proceed with changes; while they just did.
+19:53:09 <bremner> OdyX: I think implicitly recognizing the way they proceeded was not OK
+19:53:22 <OdyX> you have a point
+19:53:35 <ansgar> Mithrandir: I mean, yes, there are social problems and going ahead with the NMU is not great. But what should the ctte do about it now?
+19:53:42 <marga> Alright, so I guess there's some consensus that it's ok for the init-system-helpers maintainers to be the gatekeepers, as any new init system should fulfill certain criteria, but the maintainers should better specify what this criteria is.
+19:53:52 <OdyX> *could
+19:54:01 <ntyni> fwiw it was an init-system-helpers maintainer (Michael Biebl) who suggested involving CTTE to define the criteria
+19:54:20 <marga> Ah, but we are not asked that
+19:54:47 <marga> Or well, I guess we are... I had misread that.
+19:55:06 <Mithrandir> ansgar: that's the question we are being asked, by the NMUer, no less.
+19:56:16 <OdyX> I'd be fine with saying "as things stand, we recognize that the bin:init maintainers are the effective gatekeeper, but it's fine as is; we just recommend that they specify their requirements better, in a README.Debian for example"
+19:57:51 <ntyni> something like that would work for me I think
+19:58:14 <OdyX> if they explicitely come back to us asking for the guidelines, we can help (as individuals, not as TC))
+19:58:29 <bremner> well, the TC can provide advice
+20:00:11 <ansgar> I think systemd-sysv had the same problem in the past:
+20:00:12 <bremner> (under point 5)
+20:00:22 <marga> ansgar, which problem?
+20:00:31 <ansgar> you had to remove sysvinit which was essential and providing /sbin/init.
+20:01:12 <marga> Ah, you mean early on
+20:01:32 <ansgar> And that was actually an essential package, so apt would try to install it again, removing systemd-sysv.
+20:01:38 <Mithrandir> yeah, that's how it was for wheezy and half of the jessie cycle until we switched the default, again.
+20:01:46 <Mithrandir> -again
+20:02:07 <marga> Oh, we are over time...
+20:02:22 <marga> It seems we have a consensus as to how to move forward, though
+20:02:35 <marga> Can someone take the action item to reply to this?
+20:03:30 <ntyni> I suppose I can try
+20:04:31 <marga> #action ntyni to reply to the reporter with the consensus obtained on IRC
+20:04:36 <marga> Thanks!
+20:04:48 <marga> And with that, I'll end the meeting, given that we are over time
+20:04:51 <marga> #endmeeting
\ No newline at end of file
--- /dev/null
+====================
+#debian-ctte Meeting
+====================
+
+
+Meeting started by marga at 19:00:20 UTC. The full logs are available at
+http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-03-20-19.00.log.html
+.
+
+
+
+Meeting summary
+---------------
+* Roll Call (marga, 19:00:29)
+
+* Review of previous meeting AIs (marga, 19:03:12)
+ * LINK:
+ http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-02-20-18.58.html
+ is the summary of the previous meeting (marga, 19:03:32)
+
+* #904558 What should happen when maintscripts fail to restart a service
+ (marga, 19:05:45)
+ * ACTION: marga to send mail to the bug saying that: Debian cannot be
+ consistent with current infrastructure but we recommend developing
+ the infrastructure that would allow consistency, by forming a
+ working group. (marga, 19:34:55)
+
+* #923450 Requirements for being pre-dependency of bin:init (marga,
+ 19:35:37)
+ * ACTION: ntyni to reply to the reporter with the consensus obtained
+ on IRC (marga, 20:04:31)
+
+Meeting ended at 20:04:51 UTC.
+
+
+
+
+Action Items
+------------
+* marga to send mail to the bug saying that: Debian cannot be consistent
+ with current infrastructure but we recommend developing the
+ infrastructure that would allow consistency, by forming a working
+ group.
+* ntyni to reply to the reporter with the consensus obtained on IRC
+
+
+
+
+Action Items, by person
+-----------------------
+* marga
+ * marga to send mail to the bug saying that: Debian cannot be
+ consistent with current infrastructure but we recommend developing
+ the infrastructure that would allow consistency, by forming a
+ working group.
+* ntyni
+ * ntyni to reply to the reporter with the consensus obtained on IRC
+* **UNASSIGNED**
+ * (none)
+
+
+
+
+People Present (lines said)
+---------------------------
+* marga (62)
+* OdyX (32)
+* Mithrandir (27)
+* bremner (23)
+* gwolf (22)
+* ansgar (12)
+* ntyni (11)
+* MeetBot (2)
+
+
+
+
+Generated by `MeetBot`_ 0.1.4
+
+.. _`MeetBot`: http://wiki.debian.org/MeetBot
--- /dev/null
+19:00:03 <marga> #startmeeting
+19:00:03 <MeetBot> Meeting started Wed Apr 17 19:00:03 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
+19:00:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+19:00:09 <marga> #topic Roll Call
+19:00:15 <marga> Margarita Manterola
+19:01:59 <OdyX> Didier Raboud
+19:02:57 <marga> :-/
+19:03:11 <marga> Gunnar said that he wouldn't be able to attend.
+19:03:30 <marga> I didn't see anything from the rest, did anybody else say they weren't coming?
+19:05:12 <marga> Alright, let's move on. I guess it's just the two of us...
+19:05:19 <OdyX> Cute :-)
+19:05:24 <marga> #topic Review of previous meeting AIs
+19:05:33 <marga> http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-03-20-19.00.html
+19:05:40 <marga> Is the log of the previous meeting
+19:05:56 <marga> We had two AIs and failed at both, and so we still have the same two bugs open...
+19:06:13 <OdyX> yeah. No input happened whatsoever on either.
+19:06:20 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
+19:06:32 <marga> So, I drafted this: https://oasis.sandstorm.io/grain/Wh98knZvAHaZgdzqp4DYQE
+19:06:49 <marga> It's an etherpad on sandstorm, I couldn't find if there was a better pad to be used.
+19:07:05 <marga> I guess I'd appreciate feedback on it, and then I'd send it after the meeting.
+19:07:31 <OdyX> it needs login ftr
+19:07:41 <marga> ah :(
+19:07:56 <OdyX> I usually use either https://framapad.org or https://pad.riseup.net
+19:08:01 <marga> Try now?
+19:08:10 <OdyX> better
+19:08:17 <OdyX> ah no, not better
+19:08:19 <OdyX> sorry.
+19:08:30 <marga> Ok, will move to rise up, give me a sec
+19:08:57 <marga> https://pad.riseup.net/p/ntoBv46kJXfLrKEDQSz_
+19:10:54 <OdyX> I'd expand slightly on the "the TC does not engage"
+19:11:16 <OdyX> the core point is that we can't do it _as a body_, and we need larger help.
+19:12:48 <OdyX> otherwise, it's good.
+19:13:01 <marga> Ok, I've added an extra sentence, is that enough, or more?
+19:13:04 <OdyX> Maybe propose a place to gather that working-group.
+19:13:16 <marga> -project? -devel?
+19:14:54 <OdyX> hrm. Both seem suboptimal.
+19:15:05 <Mithrandir> hi, sorry for being late, I was in a car.
+19:15:21 <marga> I don't think we have a no-bikeshedding-development list
+19:15:32 <OdyX> Any working group will need guidance and steering
+19:16:01 <OdyX> and that one will need someone™ with time.
+19:16:51 <smcv> hi
+19:17:10 <smcv> sorry for the delay, reading scrollback
+19:17:34 <marga> Hi, Mithrandir and smcv. I was asking OdyX for feedback on https://pad.riseup.net/p/ntoBv46kJXfLrKEDQSz_ which is what I intend to send to close the maintscripts bug
+19:18:01 <marga> Happy to hear your feedback as well
+19:20:01 <smcv> my only reservation about this is that it's very possible that it's going to give us another Debian-specific solution that no other distro uses, resulting in Debian maintaining a weird Debianism for all time
+19:20:31 <marga> RIght, but this is a need that all distros have, no?
+19:20:59 <smcv> all distros that do significant surgery on a running system, at least
+19:21:07 <marga> So, maybe include that if possible this should be distro-agnostic and shared with other distros?
+19:21:18 <smcv> perhaps
+19:21:41 <smcv> on one hand, maintainer scripts (in the form that they take in Debian) *are* very Debian-specific
+19:21:49 <marga> Yes
+19:21:56 <marga> But notifying maintainers is a common problem.
+19:22:07 <marga> sysadmins, sorry
+19:22:14 <marga> It's a common, unsolved problem.
+19:22:15 <smcv> on the other hand, "like o.fd.Notifications, but for the OS" is not a distro-specific need
+19:23:06 <smcv> I'm not saying the solution should necessarily involve D-Bus, but it would be nice if it didn't involve too many Debian-specific interfaces either
+19:23:21 <marga> Yup
+19:23:54 <smcv> for instance something that's full of deb822 would not be likely to encourage cross-distro or cross-desktop or otherwise cross-ecosystem communication
+19:23:57 <marga> I'm wary of having dbus in the pipeline, but I guess that at this point it's in the pipeline of so many things already...
+19:24:03 <OdyX> Not making it systemd-specific will be… costly.
+19:24:34 <marga> Anyway, let's not go into design :)
+19:25:04 <marga> Is there something else we should recommend regarding how the group should be formed / operate?
+19:25:13 <smcv> yeah, the only reason I mentioned D-Bus is that o.fd.Notifications is an example of an interface that *has* been widely successful cross-desktop and cross-distro
+19:25:34 <Mithrandir> that mail looks reasonable to me, fwiw.
+19:25:37 <smcv> and it might be mistaken for a solution to this need (it isn't suitable, but it's in a vaguely similar space)
+19:26:51 <smcv> mail looks good to me
+19:26:57 <marga> ok, thanks
+19:27:10 <marga> #topic #923450 Requirements for being pre-dependency of bin:init
+19:27:52 <marga> Last time we discussed this at length and gave the AI to Niko to reply to the bug
+19:28:28 <marga> I think OdyX had summarized the consensus as: "as things stand, we recognize that the bin:init maintainers are the effective gatekeeper, but it's fine as is; we just recommend that they specify their requirements better, in a README.Debian for example"
+19:29:18 * smcv reads last time's minutes
+19:29:35 <marga> The minutes are too short. I'm skimming through the log
+19:29:54 <smcv> yeah, sorry, that's what I meant
+19:30:43 <smcv> I think something I would want to see in any set of requirements for being an init implementation is the principle that asking to be an init alternative should be the last thing you do before your init is ready for wide use
+19:31:39 <OdyX> indeed
+19:31:40 <smcv> as in, replacing the default init or another well-supported init with your new init should result in a system that still basically works and is supportable
+19:31:51 <smcv> not a system that needs a lot of handholding to be usable
+19:32:08 <marga> Sure. But what does it mean for a system to work and be supportable? That's part of what the guidelines should say
+19:32:17 <smcv> (I don't know where runit is on a scale from "needs lots of handholding" to "everything works like you'd expect")
+19:32:22 <marga> The reporter asked us to write those guidelines
+19:32:34 <marga> And we said that they should be written by the maintainers of the package.
+19:33:13 <OdyX> It's very different to be in the install path of a "init" package, and being the default
+19:34:04 <marga> smcv, to recap the original bug: first it needed a lot of handholding, the systemd maintainers tested it and reported issues. The runit dev fixed those issues and came back. They tested it again, it still needed some handholding. After a couple of rounds they stopped responding to the bug. Eventually the runit maintainer uploaded an NMU to delayed that was nacked by mail, but allowed to proceed and not reverted and it's what's in testing now.
+19:36:04 <smcv> on one hand it's hard to swap init implementation to one that init doesn't have as an alternative, and that holds back adoption of non-default inits
+19:36:33 <marga> Yeah
+19:36:33 <smcv> on the other hand how many inits is every system service maintainer expected to be able to support?
+19:36:55 <marga> Only systemd and sysv?
+19:36:58 <ansgar> smcv: All currently?
+19:37:37 <OdyX> FSVO "support"
+19:38:06 <OdyX> The expectation is AFAIK "merge reasonable-looking patches, test on your usual init"
+19:42:28 <marga> So, last time we seemed to have consensus on letting the systemd maintainers own the guidelines. Just asking them to publish them
+19:43:33 <OdyX> I haven't moved much
+19:43:51 <marga> smcv, do you think you can take the AI of closing the bug?
+19:44:13 <marga> You seem to have ideas of what the guidelines should be, so you can maybe add those, as your personal suggestions. :)
+19:44:16 <smcv> would it maybe be helpful to suggest having a lower bar for accepting init alternatives in experimental than in unstable?
+19:45:04 <smcv> ok, I'll try to summarize on the bug this weekend
+19:45:19 <marga> Thanks@
+19:45:27 <smcv> with a reply with my own suggestions (or something)
+19:45:40 <Mithrandir> fwiw, as systemd maintainer, we did not have much trouble with not shipping /sbin/init for a while and just recommending people use init= in grub.
+19:46:20 <marga> #action smcv to close the bug letting parties know that we think the status quo of systemd maintainers being gatekeepers is ok, and that they should publish the guidelines for inclusion.
+19:46:53 <marga> Alright, let's move on to 'Any other business'
+19:46:58 <marga> #topic Any other business
+19:47:33 <OdyX> How was the perspective of half-DPLship marga?
+19:47:42 <marga> scary
+19:47:56 <marga> But I guess I encouraged enough people to run :)
+19:48:24 <marga> I read something about DebConf in the backlog. Who's planning on attending? Should we have the traditional TC talk?
+19:48:38 <marga> I'm planning to go but I haven't finalized my plans yet.
+19:49:36 <smcv> I won't be at debconf this time round
+19:49:49 <OdyX> Not this year either.
+19:52:14 <marga> Mithrandir, ?
+19:54:15 <marga> I guess he went away.
+19:54:30 <marga> Anyway, it seems there's nothing else to discuss, so let's close now
+19:54:35 <marga> #endmeeting
\ No newline at end of file
--- /dev/null
+====================
+#debian-ctte Meeting
+====================
+
+
+Meeting started by marga at 19:00:03 UTC. The full logs are available at
+http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-04-17-19.00.log.html
+.
+
+
+
+Meeting summary
+---------------
+* Roll Call (marga, 19:00:09)
+
+* Review of previous meeting AIs (marga, 19:05:24)
+ * LINK:
+ http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-03-20-19.00.html
+ (marga, 19:05:33)
+
+* #904558 What should happen when maintscripts fail to restart a service
+ (marga, 19:06:20)
+ * LINK: https://pad.riseup.net/p/ntoBv46kJXfLrKEDQSz_ (marga,
+ 19:08:57)
+
+* #923450 Requirements for being pre-dependency of bin:init (marga,
+ 19:27:10)
+ * ACTION: smcv to close the bug letting parties know that we think the
+ status quo of systemd maintainers being gatekeepers is ok, and that
+ they should publish the guidelines for inclusion. (marga, 19:46:20)
+
+* Any other business (marga, 19:46:58)
+
+Meeting ended at 19:54:35 UTC.
+
+
+
+
+Action Items
+------------
+* smcv to close the bug letting parties know that we think the status
+ quo of systemd maintainers being gatekeepers is ok, and that they
+ should publish the guidelines for inclusion.
+
+
+
+
+Action Items, by person
+-----------------------
+* smcv
+ * smcv to close the bug letting parties know that we think the status
+ quo of systemd maintainers being gatekeepers is ok, and that they
+ should publish the guidelines for inclusion.
+* **UNASSIGNED**
+ * (none)
+
+
+
+
+People Present (lines said)
+---------------------------
+* marga (60)
+* smcv (24)
+* OdyX (23)
+* Mithrandir (3)
+* MeetBot (2)
+* ansgar (1)
+
+
+
+
+Generated by `MeetBot`_ 0.1.4
+
+.. _`MeetBot`: http://wiki.debian.org/MeetBot
--- /dev/null
+18:59:44 <marga> #startmeeting
+18:59:44 <MeetBot> Meeting started Wed Jun 19 18:59:44 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
+18:59:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+18:59:51 <marga> #topic Roll Call
+19:00:01 <marga> Who's here for this month's meeting?
+19:00:06 <marga> Margarita Manterola
+19:00:07 <fil> Philip Hands
+19:00:12 <ntyni> Niko Tyni
+19:00:12 <bremner> sorta here. on s bahn back to htel
+19:01:11 <marga> Ok, I guess that's all of us...
+19:01:12 <marga> #topic Review of previous meetings AIS
+19:01:29 <marga> So, we closed one bug and the other one smcv sent the update, but didn't close the bug.
+19:02:24 <marga> I think it wasn't intentional, though (i.e. everything that's needed is there, only the closing is missing as far as I'm concerned)
+19:02:43 <marga> Let's switch into that bug and see if we agree on that :)
+19:02:50 <marga> #topic #923450 Requirements for being pre-dependency of bin:init
+19:03:16 <marga> I think the only action left is to actually close the bug. Am I missing something or can we just close it?
+19:03:55 <fil> I think that's right
+19:04:52 <ntyni> me too; might be worth checking with smcv if he had something else in mind though
+19:05:18 <marga> Alright, then we can close the bug. I'll take the AI to ping smcv and check whether he had something else in mind.
+19:05:35 <marga> #action marga to check with smcv if this can be closed already.
+19:05:49 <marga> Ok, so now for the fun topic of the day...
+19:05:51 <marga> #topic Sam's thread about "Delegating decisions about Policy"
+19:06:05 <bremner> yeah it looked OK toe
+19:06:26 <marga> So, we had this thread where Sam asked about future decisions about policy and whether the TC would be the right body to do that and more fun stuff...
+19:06:56 <marga> Nobody in the TC replied to the thread. Sean and Ian had a nice conversation, up until the point where Ian started saying that the TC is flawed by (his) design...
+19:07:19 <marga> So, I'm wondering what the others think about this thread, whether we should respond something, etc
+19:08:55 <marga> I think the question boils down to whether the TC is the authority on technical policy, for things that were not elevated to us through the usual process, but rather to establish new policies for the project.
+19:11:04 <ntyni> "The Technical Committee does not engage in design of new proposals and policies."
+19:11:17 <marga> Indeed, but Sam's question is not about design
+19:11:25 <marga> Rather about establishing policy
+19:11:46 <marga> Say that we wanted the whole project to adopt some new standard or something like that
+19:12:40 <fil> My gut reaction is that the TC isn't really for this. I'm happy with the TC being responsible for the things that people cannot sort out amongst themselves, but not if we're expected to poke our nose into some specialist area where everyone is cheerfully working together.
+19:12:43 <ansgar> marga: Isn't that "design of new policies"?
+19:13:36 <marga> ansgar, I guess it's a bit of a gray area. If the standard already exists and we say that that's the standard that we should adopt, are we actually designing a new policy or not?
+19:13:37 <fil> of course, project wide change is another thing, but I don't really see that we're somehow elevated above others in the project when it comes to deciding that sort of thing
+19:13:43 <marga> But, yeah, I kinda feel that this is not the right role for the TC, and personally I think the right way to go is to let the policy maintainers feel empowered to take these decisions and then involve us only when they are not sure.
+19:14:38 <bremner> there is a bigger question about policy leading practice imho
+19:16:25 <ansgar> marga: And then there is also "Technical Committee makes decisions only as last resort"; (one could change that of course if really wanted)
+19:17:58 <marga> Right, that's true
+19:18:32 <marga> I'm not sure how that would combine with a separate delegation, which I think was what Sam had in mind
+19:18:47 <marga> But, I think we are basically in agreement that the role proposed by Sam doesn't really fit the TC
+19:19:09 <bremner> I think tc might have a role if policy editors don't see cocncencus
+19:19:16 <fil> bremner: quite -- policy strikes me as being akin to English dictionaries (following common usage, rather than trying to set it)
+19:19:25 <ansgar> bremner: Or policy documenting things that never were practice (doc-base for example; or other things)
+19:20:58 <ntyni> yeah missing consensus fits in with the "last resort" thing
+19:21:41 <marga> Ok, it seems that we are basically in agreement about this: TC can be consulted when policy editors don't see consensus, but we feel it's the role of policy editors to decide on what to do about policy.
+19:21:48 <marga> Does that represent the general agreement correctly?
+19:22:07 <ntyni> works for me
+19:22:20 <bremner> OK for me
+19:23:01 <marga> Ok, shall I reply to Sam, or does someone feel strongly inclined to take this?
+19:23:30 <fil> something like that -- although I'd expect the best policy to come out of some grouping of interested developers pushing changes at the policy editors, but that's a detail
+19:24:04 <ansgar> So, what about issues that won't see consensus? Say doc-base...
+19:24:53 <marga> I think that in that case it makes sense to ask the TC to weigh in. But we'd only do it after being asked, i.e. "last resort"
+19:24:58 <ansgar> I proposed to remove it as I think it never gained much use; mostly to get rid of unused stuff in policy.
+19:25:21 <ansgar> But I don't feel like investing much energy it getting it removed (I just ignore it like everyone else)
+19:26:02 <bremner> well, probably the TC is also not for things you don't want to invest much energy in ;)
+19:26:20 <fil> ansgar: sounds like something to be added to the papercuts list?
+19:28:04 <fil> I'd imagine that most people would agree to just drop it at this point, since as you say, it mostly gets ignored
+19:28:21 <marga> Yeah, where's the lack of consensus there?
+19:30:13 <ansgar> marga: Well, someone wanted to push for doc-base adoption instead. So Policy is at a standstill.
+19:30:47 <ntyni> this is #910783 fwiw
+19:31:09 <marga> Ok. So, I think this would be something that the TC could consider, but it would require someone bringing this up
+19:31:41 <ansgar> If you want something with more disagreement, there is also #911165 ;-)
+19:31:54 <marga> One thing that worried me from one of Ian's messages was that he brought up the fact of how much friction bringing things up to the TC means.
+19:32:17 <marga> I'd like for people to be able to bring things up to the TC without it becoming a flamewar, but I don't know if that's actually possible.
+19:33:17 <fil> we do _almost_ have a rule that it has to be a flamewar before you bring it to the TC though ;-)
+19:34:00 <marga> Well, that's not really it, and maybe there's something for us to change there? We want people to first try to discuss and agree... Not go through a flamewar
+19:34:27 <ansgar> I probably would bring it to the TC if someone asked for a package to be removed because it has no sysvinit script.
+19:34:56 <ansgar> But just policy having that requirement and reality disagreeing is not that large a problem ;-)
+19:35:01 * gwolf arrives, panting...
+19:35:22 <marga> ok
+19:35:22 <bremner> marga: we could consider some concensus building exercises
+19:35:33 <marga> bremner, what do you mean?
+19:35:41 <ansgar> So I guess one could ask if the TC wanted to be proactive about such standstills in policy.
+19:35:57 <bremner> marga: well, basically what sam just did for dh.
+19:36:21 <bremner> ansgar: I think you should talk to the policy editors about standstills in policy
+19:37:05 <marga> yup
+19:37:27 <ansgar> bremner: Well, I think there is no consensus... So not sure what policy editors should do?
+19:37:38 <bremner> ansgar: it's their process to manage.
+19:37:39 <fil> bremner: I think that's a good idea, but on the other hand I don't think that we have any monopoly on that sort of thing, so anyone could do such an effort
+19:38:13 <bremner> fil: I was think as alternative to just closing bugs because people haven't tried to build concensus
+19:38:20 <bremner> I'm not sure I personally have the tuits
+19:38:29 <marga> Ah, I see what you mean now
+19:38:53 <marga> Like instead of saying: "go discuss and come back when you haven't been able to agree", to work with them to find consensus?
+19:38:59 <gwolf> FWIW I agree with the points I have read, and particularly with marga's conclusions...
+19:39:00 <bremner> yeah, something like that
+19:39:18 <marga> Yeah, I think that would be valuable, but we'd need to know how to do it :)
+19:39:25 <fil> Sam does seem to have done a particularly good job on that one -- I wonder if it would have gone as well if he were not DPL, and what we could do to support non-DPLs in making similar efforts
+19:39:28 <bremner> marga: I think moderating discussion doesn't count as detailed design
+19:39:41 <bremner> ymmv
+19:40:15 <marga> bremner, I agree with that assessment, I just think it's a different skillset than the one usually requested for someone joining the TC
+19:40:30 <gwolf> I believe that one of the criteria and reasons for selecting people to TC is to try to compose the TC of non-flamewarists
+19:40:53 <bremner> well, it's mainly a process thing, and sam has just had practice. He'd probably help with getting started
+19:41:25 <marga> Yeah, that might help
+19:42:01 <gwolf> marga: I think the way you frame it ("come back when...") would be just the wrong way to put it :) Maybe we should try to steer things into agreeing instead of requiring proof of flame
+19:42:32 * gwolf supports bremner "moderating discussion is not detailed design"
+19:42:33 <fil> BTW I think it would have gone pretty-much as well had he not been DPL, in case that wasn't clear
+19:43:07 <marga> Yeah, but maybe he wouldn't have been motivated to be involved.
+19:43:30 <marga> Anyway, I think we sort of have consensus here, and I'll reply to Sam's email when I don't have a headache like I do right now :-/
+19:43:37 <marga> Let's move to AOB
+19:43:42 <marga> #topic Any other business?
+19:45:48 <marga> I guess not, then :)
+19:45:50 <gwolf> Shall we prepare something for our DebConf talk?
+19:45:58 <marga> What do you have in mind?
+19:46:07 <gwolf> I guess we can basically rehash what we used in previous confs
+19:46:14 * fil won't be there I'm afraid
+19:46:23 <gwolf> (that's something we can sort out face to face, so no reason in having it in-meeting)
+19:46:32 * ntyni neither
+19:46:33 <gwolf> I just wanted to say something meeting-worthy ;-)
+19:46:37 <marga> I think it would be nice to do something different, btw
+19:46:42 <fil> lol
+19:46:43 <marga> But we should probably discuss in person
+19:46:57 <gwolf> right - but we should start thinking what we want to do
+19:47:12 <marga> Agreed
+19:47:15 <marga> I'll think about
+19:47:25 <marga> #endmeeting
\ No newline at end of file
--- /dev/null
+====================
+#debian-ctte Meeting
+====================
+
+
+Meeting started by marga at 18:59:44 UTC. The full logs are available at
+http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-06-19-18.59.log.html
+.
+
+
+
+Meeting summary
+---------------
+* Roll Call (marga, 18:59:51)
+
+* Review of previous meetings AIS (marga, 19:01:12)
+
+* #923450 Requirements for being pre-dependency of bin:init (marga,
+ 19:02:50)
+ * ACTION: marga to check with smcv if this can be closed already.
+ (marga, 19:05:35)
+
+* Sam's thread about "Delegating decisions about Policy" (marga,
+ 19:05:51)
+
+* Any other business? (marga, 19:43:42)
+
+Meeting ended at 19:47:25 UTC.
+
+
+
+
+Action Items
+------------
+* marga to check with smcv if this can be closed already.
+
+
+
+
+Action Items, by person
+-----------------------
+* marga
+ * marga to check with smcv if this can be closed already.
+* **UNASSIGNED**
+ * (none)
+
+
+
+
+People Present (lines said)
+---------------------------
+* marga (55)
+* bremner (16)
+* fil (14)
+* ansgar (12)
+* gwolf (10)
+* ntyni (7)
+* MeetBot (2)
+
+
+
+
+Generated by `MeetBot`_ 0.1.4
+
+.. _`MeetBot`: http://wiki.debian.org/MeetBot
--- /dev/null
+18:59:44 <marga> #startmeeting
+18:59:44 <MeetBot> Meeting started Wed Jul 17 18:59:44 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
+18:59:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+18:59:52 <marga> #topic Roll Call
+19:00:04 <marga> Margarita Manterola
+19:00:09 <bremner> David Bremner
+19:02:24 <fil> Philip Hands
+19:03:28 <marga> And I think that's probably all of us.
+19:03:36 <marga> #topic Review of previous meetings AIs
+19:03:59 <marga> Previous meeting is at: http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-06-19-18.59.html
+19:04:37 <marga> I had 2 AIs (one that I didn't actually #action myself for): to talk with smcv about closing the bug that he replied to but didn't close, and one about replying to Sam's thread with the outcome of our discussion last month.
+19:04:58 <marga> I failed at both :( [It's been an extremely busy month]
+19:05:17 <marga> Either of you feels like taking on one of those tasks?
+19:05:29 <fil> I'll prod smcv
+19:05:59 <bremner> I'm not sure I have the discussion for item #2 very fresh in my mind, I'd have to check the logs.
+19:06:17 <fil> and which Sam thread are we on about? (sorry about that -- *snap*)
+19:07:34 <marga> Fortunately meetbot is here to help us: http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-06-19-18.59.log.html has the full discussion
+19:07:47 <marga> The thread is "Delegating decisions about Policy"
+19:08:47 <marga> The consensus was the deciding policy is not the right role for the TC, as far as I recall / can tell from a quick re-read
+19:09:46 <bremner> yeah, that looks roughly right. or put it more procedurally, that the TC is reactive by design. So if people want advice they can ask
+19:10:45 <marga> Yeah. It's now been quite a while since the thread died down, but I still feel bad that nobody from the TC replied
+19:10:49 <bremner> maybe we can discuss a bit further with Sam at the TC BoF
+19:11:08 <bremner> unfortunately only a small subset of us
+19:11:13 <marga> yeah...
+19:11:29 <bremner> or we can reply pre-BoF and discuss the reply if needed
+19:11:34 <marga> Ok, I'll action fil about the other thing
+19:11:57 <marga> #action fil to prod smcv about closing #923450
+19:12:08 <bremner> marga: I can promise to give feedback quickly on a draft for #2, does that help?
+19:12:29 <marga> Uhm, ok, I guess
+19:12:46 <bremner> or I could start the ball, but I think it needs more than just me to write.
+19:13:00 <marga> #action marga & bremner to work on drafting a reply to Sam's thread about "Delegating decisions about Policy"
+19:13:21 <marga> #topic Any other business?
+19:13:56 <marga> bremner, you'll be in Curitiba, then?
+19:14:04 * fil prods smcv on IRC -- will mail if he doesn't notice
+19:14:10 <bremner> marga: I'm already there (here)
+19:14:28 <marga> Ah, cool :). I'm in Buenos Aires now, flying there on Friday.
+19:14:32 <bremner> yay!
+19:14:39 <fil> I'm happy to help with that BTW
+19:15:09 <fil> but if you're going to be in the same room, that's probably easier
+19:15:15 <marga> I know fil, ntyni, and OdyX are not going. And gwolf is currently on the way there. Do we know about smcv and Mithrandir?
+19:15:27 <bremner> Mithrandir is coming iirc
+19:16:03 <fil> have fun BTW :-)
+19:16:06 <marga> Ok :)
+19:16:32 <bremner> I guess that's it for other (non)-business?
+19:16:38 <marga> Alright, I think actually talking about the role of the TC during the BOF might make it more interesting than in previous years. We'll see.
+19:16:45 <marga> Thanks and yes.
+19:16:48 <marga> #endmeeting
\ No newline at end of file
--- /dev/null
+====================
+#debian-ctte Meeting
+====================
+
+
+Meeting started by marga at 18:59:44 UTC. The full logs are available at
+http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-07-17-18.59.log.html
+.
+
+
+
+Meeting summary
+---------------
+* Roll Call (marga, 18:59:52)
+
+* Review of previous meetings AIs (marga, 19:03:36)
+ * ACTION: fil to prod smcv about closing #923450 (marga, 19:11:57)
+ * ACTION: marga & bremner to work on drafting a reply to Sam's thread
+ about "Delegating decisions about Policy" (marga, 19:13:00)
+
+* Any other business? (marga, 19:13:21)
+
+Meeting ended at 19:16:48 UTC.
+
+
+
+
+Action Items
+------------
+* fil to prod smcv about closing #923450
+* marga & bremner to work on drafting a reply to Sam's thread about
+ "Delegating decisions about Policy"
+
+
+
+
+Action Items, by person
+-----------------------
+* bremner
+ * marga & bremner to work on drafting a reply to Sam's thread about
+ "Delegating decisions about Policy"
+* fil
+ * fil to prod smcv about closing #923450
+* marga
+ * marga & bremner to work on drafting a reply to Sam's thread about
+ "Delegating decisions about Policy"
+* **UNASSIGNED**
+ * (none)
+
+
+
+
+People Present (lines said)
+---------------------------
+* marga (26)
+* bremner (12)
+* fil (7)
+* MeetBot (2)
+
+
+
+
+Generated by `MeetBot`_ 0.1.4
+
+.. _`MeetBot`: http://wiki.debian.org/MeetBot
projects / debian-ctte.git / commitdiff