17:59:51 <spwhitton> #startmeeting
17:59:51 <MeetBot> Meeting started Wed Oct 13 17:59:51 2021 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:51 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:01 <spwhitton> #topic Roll Call
18:00:03 <spwhitton> Sean Whitton
18:00:11 <Myon> Christoph Berg
18:00:13 <marga> Margarita Manterola
18:00:17 <bremner> David Bremner
18:00:25 <ntyni> Niko Tyni
18:00:51 <smcv> Simon McVittie
18:01:08 <ehashman> Elana Hashman
18:01:23 <gwolf> Gunnar Wolf
18:01:28 <spwhitton> great to see everyone
18:01:30 <ehashman> full house
18:01:32 <spwhitton> #topic Review of previous meeting AIs
18:01:34 <gwolf> \o/
18:01:44 <spwhitton> I did my recruitment stuff but not the Jitsi thing.  Gonna reaction myself.
18:01:59 <spwhitton> #action to look into Jitsi for next time
18:02:06 <spwhitton> smcv did his; we will discuss later
18:02:09 <spwhitton> marga, bremner?
18:02:11 <marga> http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-09-08-17.59.html
18:02:11 <bremner> I did (sortof) the early invocation thing. Needs review / editing
18:02:27 <spwhitton> bremner: coolio, is it in a branch or something?
18:02:47 <bremner> I yolo'd it to master with a disclaimer at the top
18:02:56 <marga> I didn't do whatever I had to do
18:03:07 <marga> I'm confused by the notes, though. I thought I had to do a different thing
18:03:27 <spwhitton> marga: yeah I typoed the #action.  it was meant to be private communication.
18:03:53 <spwhitton> do you think you could do it for next time?
18:04:07 <marga> Yeah...
18:04:15 <spwhitton> okay cool I'll re-action
18:04:27 <spwhitton> #action marga to commit final version of private communication to tech-ctte.git procedures/
18:04:50 <spwhitton> bremner: haven't read what you've done.  my assumption would be that only minimal review is needed because you were mainly transcribing?
18:05:16 <bremner> spwhitton: well, I rearranged I tried to compress too. So, I think it needs some review by people who were in the room
18:05:37 <spwhitton> okay.  I am just scanning and I found something to edit.
18:06:08 <spwhitton> how about we assign one person to review and edit and then remove the disclaimer, as I thinkw e can be pretty confident about consensus then?
18:06:15 <bremner> sounds good
18:06:15 <spwhitton> I would be happy to do that.
18:06:21 <spwhitton> is this okay with everyone else?
18:06:22 <bremner> even better
18:06:26 <ntyni> sure
18:06:28 <Myon> ack
18:06:34 <spwhitton> I just don't think there's much controversy, so two people ought to be enough.
18:06:49 <bremner> the feedback on the pad was pretty minimal
18:06:55 <spwhitton> #action spwhitton to review and tweak bremner's early invocation text and then remove disclaimer
18:07:07 <spwhitton> alright, anything else on these AIs or shall we move onto our bugs?
18:07:23 <bremner> I got nothin'
18:07:58 <spwhitton> thanks to everyone for their work since last meeting :)
18:08:02 <spwhitton> #topic #994388 - More specific advice regarding merged-/usr and implications of #978636
18:08:16 <spwhitton> smcv, ntyni and I have been making and reviewing changes.
18:08:25 <bremner> I also read an earlier version
18:08:44 <spwhitton> obviously people will need to give it a proper read before voting, but are we ready to call a vote, perhaps?
18:08:55 <gwolf> I have been trying to keep up, but not completely doing so :-( Too busy lately...
18:08:55 <smcv> I have one MR open
18:08:56 <bremner> unless there is controversy I missed, I think call for vote is reasonable
18:09:07 <gwolf> I agree with calling for a vote
18:09:12 <spwhitton> smcv: ah yes.  can you #link it?
18:09:23 <smcv> #link https://salsa.debian.org/debian/tech-ctte/-/merge_requests/7
18:09:31 <ehashman> I don't really have a ton to add to this one, I am fine with calling a vote
18:09:42 <bremner> smcv: there is also MR 2?
18:09:53 <bremner> oh, my bad
18:10:07 <marga> The text is really long and detailed, which is good. The summary, I found a bit confusing.
18:10:11 <smcv> I hope this is an uncontroversial change, tl;dr: be extra-clear that for things like run-parts that moved to /usr since bullseye, we expect maintainers to move them back
18:10:26 <spwhitton> smcv: it doesn't explicitly say "move them back please"
18:10:38 <smcv> it doesn't
18:10:49 <smcv> do I need to add that?
18:10:53 <bremner> should that be part of the advise?
18:11:32 <smcv> "If files were moved from /bin, /lib* or /sbin into /usr since the Debian 11 release, they should be moved back to their Debian 11 locations."
18:11:36 <smcv> something like that?
18:11:40 <spwhitton> yeah I think so
18:11:55 <bremner> will there be exceptions?
18:12:04 <spwhitton> probably
18:12:08 <spwhitton> "should in most cases be moved back"
18:12:08 <spwhitton> ?
18:12:36 <smcv> yeah seems fine
18:12:40 <bremner> ok for me
18:12:41 <spwhitton> marga: re summary, that's fair, I hadn't really looked at that part as I read text before summary was there.  we could drop the summary, or make an attempt to rewrite it; the latter means we can't call avote now.
18:12:41 <gwolf> bremner: what would warrant/require an exception?
18:12:54 <bremner> gwolf: a proper transition plan? dunno really
18:12:58 <gwolf> I guess it'd be better not to mention exceptions, and address them if somebody raises their hand in anguish
18:13:03 <bremner> maybe fixing an RC bug?
18:13:14 <gwolf> and gratiously granting said exception :-)
18:13:17 <bremner> should normally be moved back?
18:13:47 <spwhitton> I think that I would be inclined to drop the summary.  The people for whom this document is relevant are going to read whole thing.
18:13:54 <marga> Suggested summary: There are currently Debian 11 installations for both the merged-usr and not merged-usr installation. All of these installations should successfully upgrade via normal upgrade paths to a merged-usr Debian 12. Only after the release of Debian 12 can packages assume that all installations will be merged-usr. ?
18:14:05 <spwhitton> oh that would be fine too.
18:14:10 <spwhitton> smcv: thoughts on summaries?
18:14:19 <smcv> if/when we get a proper transition plan, the draft already says the TC will end the moratorium on moving stuff
18:14:27 <marga> Oh, that repeats installations way too much, should be tweaked a little.
18:14:38 <smcv> (assuming the transition plan is compatible with that)
18:15:27 <smcv> do we want to replace my summary with an even more tl;dr version with the same effect as what marga said?
18:15:36 <smcv> or drop it?
18:15:42 <spwhitton> I would be okay with either.
18:15:57 <spwhitton> I also don't have a strong view on the existing summary, to be honest -- can others have a look now and see what they think of it?
18:16:00 <marga> smcv, the problem I have with your summary is that it's not really a summary, it's an assortment of bullet points with different levels of relevance.
18:16:18 <smcv> my intention was to head off the inevitable "but but smcv wrote a document therefore it's too long and I'm going to ignore it" from certain developers
18:16:38 <marga> And I think a TL;DR is important for people to understand whether reading the whole details is relevant to them or not.
18:17:00 <Myon> the TL;DR is very important, don't remove it
18:17:14 <smcv> what I was *aiming for* was to sum up the rest of the document, in as few words as I thought I could get away with, without saying why
18:17:28 <smcv> with the intention that anyone who cares about why will read the rest of the document
18:17:33 <ntyni> yeah +1 on having at least some kind of a summary
18:17:56 <marga> Yes, please, I'm not saying it should be dropped. I want a clearer summary.
18:17:57 <smcv> and so that people who consider me to be too verbose can't use that as an excuse to ignore the whole thing
18:18:19 <Myon> the text is way too long to make any sense without any introduction about which direction it is moving to
18:18:36 <smcv> yeah
18:18:49 <smcv> I wanted the real text to be as specific as possible
18:18:50 <spwhitton> time is passing, so we could do this, if smcv has time: action simon to write a summary like marga's above, and then to start a vote once he's done that ?
18:18:50 <gwolf> smcv: What would you feel about TL;DR _before_ the rest of the document
18:19:05 <smcv> so that peope can't argue the toss about whether their pet thing is merged-/usr or not
18:19:07 <gwolf> so that the document is a detailed rationale
18:19:14 <gwolf> not a wall-of-text...
18:19:14 <smcv> gwolf: that's ... what I did?
18:19:31 <marga> smcv, not really. The bullet points are very confusing
18:19:43 <gwolf> smcv: Right, that's what I meant
18:19:47 <smcv> I'm sorry, I did my best
18:19:58 <marga> Again, suggested summary: There are currently Debian 11 installations for both the merged-usr and not merged-usr filesystem layouts. All of these installations should successfully upgrade via normal upgrade paths to a merged-usr Debian 12. Only after the release of Debian 12 can packages assume that all installations will be merged-usr.
18:20:05 <ntyni> maybe something like marga's shorter version at the top, and the current summary at the bottom?
18:20:46 <smcv> marga: sounds good to me fwiw
18:21:01 <smcv> let's see whether salsa can do live edits
18:21:10 <spwhitton> okay so, smcv, are you okay to be assigned to replace/insert/similar something like marga's text, and then start a vote?
18:21:51 <smcv> yeah
18:22:02 <smcv> do we want my bullet points to go away completely
18:22:17 <bremner> I would like to keep the bullet points
18:22:23 <smcv> or move to the end as a more concise restatement of the rest of the document?
18:22:24 <spwhitton> I would be happy if they were just not the first thing in the document.  other people might find it a very useful summary.
18:22:33 <Myon> keep the summary at the beginning
18:22:35 <spwhitton> so, either after the tldr or at the end.  we can leave it up to you?
18:22:48 <Myon> two tl;dr sections at different ends won't help
18:22:53 <spwhitton> I'm going to #action and move us on to the next items
18:23:08 <spwhitton> thank you for feedback and especially thank you to smcv for the tremendous amount of work on this one
18:23:22 <bremner> I suggest just label the current bullet points as "main points" or something
18:23:31 <spwhitton> #action smcv to make summary/tldr changes based on meeting discussion and then start a vote on #994388
18:23:38 <spwhitton> #topic #994275 - Reverting breaking changes in debianutils
18:24:39 <spwhitton> alright.  smcv sent a summary to our private alias a couple of days ago.  has everyone seen that?
18:25:01 <smcv> let's do the least controversial part of this first, since it touches on what we just discussed
18:25:13 <smcv> (namely /usr moves)
18:25:22 <bremner> yeah, that seems settled
18:25:27 <spwhitton> well it's basically completely uncontroversial.  we agree with adrian.
18:25:32 <bremner> but here we are asked for more than advice?
18:26:00 <bremner> should we publish the advice first before being more heavy-handed?
18:26:24 <spwhitton> bremner: I think it's okay not to worry too much about publication order for the two bugs.
18:26:36 <smcv> Adrian's points 2-5 ask us to overrule the debianutils maintainer
18:26:55 <spwhitton> bremner: the debianutils bug is not really about merged-/usr.
18:27:03 <smcv> so I think the result of those should be either "overrule" or "decline to overrule"
18:27:08 <smcv> not just advice
18:27:11 <gwolf> Not _really_, but sounds like a reaction to it by the maintainer
18:27:24 <gwolf> but yes, agree with smcv
18:27:53 <bremner> I feel like Adrian is asking for too much specificity overall.
18:28:05 <bremner> also, why are people still using "which" in 2021
18:28:22 <bremner> neither of those points is really important to the bug
18:28:27 <Myon> "which" is part of the things people expect on the command line
18:28:33 <smcv> I think "people shouldn't be using which" is true, but a red herring
18:28:39 <Myon> "command -v" isn't catchy enough
18:28:41 <smcv> it's Essential, and people *are* using it
18:28:43 <marga> Yeah, I use which very often.
18:28:45 <bremner> ack
18:28:48 <smcv> those are the important things
18:29:05 <bremner> I use interactively, but _never_ scripting, so I have a lack of sympathy to overcome
18:29:06 <Myon> I do write correct-portable-whatnot shell scripts, but "which" is good for interactive use
18:29:10 <gwolf> I always thought of it as part of Unix -- during this bug I found it was a Linux idiosincratic specificity
18:29:43 <smcv> I don't think it's Linux-specific, more like one of these annoying bits of Unix folklore that "most" OSs have but nobody ever standardized
18:29:46 <gwolf> which should probably have never been made essential -- but now it is.
18:30:17 <smcv> and, yes
18:30:32 <smcv> I sympathize with Clint not wanting it to be Essential
18:30:36 <Myon> but it doesn't have to be in debianutils
18:30:43 <bremner> ack
18:30:43 <smcv> but there's a way to take functionality out of Essential, and this is not it
18:30:56 <marga> Sure, it doesn't have to be in debianutils, but it needs to be somewhere
18:31:08 <bremner> or transitioned out
18:31:13 <bremner> gracefully
18:31:17 <smcv> right
18:31:17 <marga> Sure
18:31:24 <smcv> I think we all agree on that?
18:31:34 <bremner> so I can't agree to most of adrians wording, because of ^
18:31:59 <spwhitton> it seems we mostly agree with adrian but don't want to word it like him
18:32:09 <spwhitton> (and therefore we disagree with him.  but you get what I mean.)
18:32:27 <gwolf> right. But should we require the maintainer to coordinate for which's inclusion on any other Essential package?
18:32:28 <bremner> it's kindof "the XY" problem
18:32:48 <spwhitton> gwolf: one suggestion is that we require him to undo the change until someone else has included it somewhere else.
18:33:04 <spwhitton> for example, gnu which making it through NEW.
18:33:09 <spwhitton> and becoming transitively esesntail somehow.
18:33:32 <gwolf> Right, although that is probably going to... keep a high level of friction and unhappiness
18:33:38 <marga> What's in that package?
18:33:39 <smcv> I asked Adrian about this in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994275#105 but haven't heard back
18:33:41 <spwhitton> my wording idea for this: "the debianutils package must continue to provide which(1) until a compatible utility is available in a package that is at least transitively essential in Debian 12"
18:33:42 <Myon> the problem I have is that bunk was running into #debian-devel threatening "you (the channel) have X hours to fix this mess or else I will file a GR (or maybe just consider asking the TC)"
18:33:47 <Myon> that was real blackmail
18:34:19 <bremner> Myon: not very effective blackmail, if so?
18:34:30 <gwolf> maybe offer options to the maintainer; either re-provide the script, or coordinate for it to be included somewhere else, or wait for it to pass NEW (and depend on it or have it made effectively essential somehow)
18:34:34 <smcv> if that's the case then I'm glad he went for TC and not GR
18:34:41 <Myon> still daunting
18:34:55 <bremner> Myon: I think that's a bit like me thinking people are silly for using which in maintainer scripts. We're right, but not relevant
18:34:56 <spwhitton> gwolf: that's another option, indeed.  but I suspect it is more burdensome on Clint.
18:34:59 <Myon> maybe that's not what he meant, but it did read like that to me
18:35:48 <bremner> we can also leave it open ended like "have a transition plan approved by the TC", but that sounds slow
18:35:54 <Myon> of course it's not technically relevant, but it does make a difference in if I want to support bunk's case
18:36:12 <marga> I don't think we want to be in the critical path of approving the transition plan
18:36:14 <gwolf> bremner: I don't think we should have to approve it
18:36:17 <marga> There just needs to be a transition
18:36:23 <spwhitton> bremner: well, what do you think of the transition plan outline proposed by smcv?
18:36:40 <bremner> in the link above?
18:36:48 <spwhitton> bremner: e-mail from october 5th which I replied to yesterday
18:36:53 <spwhitton> sorry 6th
18:36:54 <smcv> a reminder that Adrian's point 1 (which must remain Essential) is currently still true
18:37:05 <smcv> there is nothing for us to overrule there
18:37:19 <smcv> Clint hasn't tried to remove which from debianutils
18:37:35 <spwhitton> id:YV11NitqPoRQ03BO@momentum.pseudorandom.co.uk id:87o87uuj37.fsf@melete.silentflame.com
18:38:03 <ntyni> fun fact: even debian-policy recommended "if which invoke-rc.d >/dev/null 2>&1" in postinst until 2017
18:38:06 <smcv> we can offer advice of the form "don't" or "only with a proper transition" if we think it is likely that he will try to remove it in future
18:38:24 <gwolf> smcv: Right. But I think we agree the deprecation notice is harsh and unwarranted, given we agree that there will still be a "which"...
18:38:26 <smcv> but we can't overrule the decision he hasn't made :-)
18:38:26 <bremner> ntyni: but if people did that they would not be complaining about output on stderr
18:38:31 <ntyni> sure
18:38:59 <spwhitton> what do people think about the combination of those two messages from simon and me
18:39:15 <smcv> point 2, removing the deprecation notice, *is* a request to overrule Clint
18:39:21 <bremner> spwhitton: not everyone has notmuch...
18:39:48 <marga> spwhitton, I'm still trying to figure out which message you're referring to :(
18:39:51 <gwolf> bremner: notmuch of what you do constitutes MUA prpaganda...
18:39:59 <spwhitton> I can re-forward to ctte alias right now if that helps?
18:40:10 <spwhitton> or bounce..?
18:40:18 <marga> I think I found it
18:40:19 <bremner> sorry, but I think there's too much there for me to consider now
18:41:10 <bremner> spwhitton: I don't have your message for some reason?
18:41:25 <spwhitton> hmmmm
18:41:28 <spwhitton> smcv: do you have it?
18:41:35 <spwhitton> oh great
18:41:41 <spwhitton> my local smtp is broken
18:41:52 <ehashman> links rather than mailids would be helpful
18:42:01 <spwhitton> ehashman: it's to private alias
18:42:07 <ehashman> ah
18:42:20 <ehashman> not https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994275#105 ?
18:42:26 <smcv> not that
18:42:43 <ntyni> I've got at least the first fwiw
18:42:52 <marga> I would rather have something shorter.  Sean's proposal sounds fine to me. And we should clearly separate between the overriding part and the advising part
18:42:52 <spwhitton> I am going to bounce it, sec
18:44:12 <gwolf> spwhitton: I am also your message
18:44:25 <gwolf> I have smcv, ntyni and mine on the thread..
18:44:26 <marga> We override the deprecation warning and the moved files. Advise that the program should not be removed until a transition is in place.
18:44:29 <spwhitton> okay just cleared my local mail queue :)
18:44:54 <gwolf> there it is!
18:44:58 <spwhitton> so sorry about that
18:45:18 <smcv> so what marga said covers Adrian's points 1 (which is Essential), 2 (overrule deprecation warning) and 5 (overrule moving to /usr)
18:45:41 <smcv> we have not covered 3 (overrule use of alternatives) and 4 (overrule removal of tempfile)
18:45:53 <bremner> what is the precise harm in 2? is is just autopkgtests failing?
18:46:09 <marga> I don't have enough context on tempfile right now. I would not overrule on alternatives.
18:46:10 <Myon> how long do we want which to stay essential? One way could be to have a which.deb pulled in for Bookworm, but allow dropping the depencency from debianutils at that point
18:46:27 <gwolf> bremner: I also see the message often when not expecting it, as many user-launchable programs do call which
18:46:30 <gwolf> i.e. firefox
18:46:30 <Myon> (when it might continue to stay essential by other means, but then it's off Clint's plate)
18:46:37 <smcv> that would be similar to what happened to sensible-utils
18:46:47 <Myon> yeah
18:47:01 <bremner> gwolf: OK, but those are in some sense bugs in the packages
18:47:07 <smcv> the problem there is that codesearch will easily tell you who is using sensible-browser (possibly without a dependency)
18:47:14 <smcv> so mass bug filing is feasible
18:47:18 <gwolf> So I don't think we will ever properly deprecate which. It might be too spread, it's used in too many places
18:47:22 <Myon> mandate a proper transition to (essential | at leat present for bookworm), but leave the rest open
18:47:26 <smcv> but I challenge you to construct a codesearch that will find users of which
18:47:42 <smcv> and not find random English text containing that extremely common word
18:47:48 <gwolf> right. code-searching for "which" will provide too many false positives
18:48:00 <bremner> I guess I can easily imagine deprecating which given some sensible transition plan
18:48:25 <smcv> so, devil's advocate time
18:48:28 <bremner> the fact that it is a shell builtin for me (and Clint) probably influences my view
18:48:33 <smcv> how do we benefit from deprecating which?
18:48:42 <gwolf> yes, although I fail to see much case in investing too much energy in deprecating a possibly-useless-but-harmless tool
18:48:46 <Myon> kilobytes saved on disk
18:49:02 <spwhitton> I don't think we need to agree on this, right?
18:49:10 <spwhitton> the issue before us is the transition
18:49:18 <marga> Yeah, we don't
18:49:21 <smcv> the changelog entries for "added deprecation warning", "removed deprecation warning", etc. are going to be bigger than the script
18:49:42 <Myon> ah it says "for the Debian 12 release." in smcv's text, missed that on the first read
18:49:50 <smcv> (I'm exaggerating slightly but not actually all that much)
18:50:50 <bremner> sure, I'd rather not be talking about which either, but I'm leery of overconstraining maintainers
18:50:59 <marga> So, I think we mostly have consensus?
18:51:01 <smcv> I'm honestly half tempted to upload debian-legacy-utils containing the shell script version of which, and a resurrected tempfile
18:51:07 <smcv> and then immediately orphan it
18:51:14 <spwhitton> yes, I think we have consensus
18:51:29 <gwolf> smcv: debian-legacy-utils will grow and grow, and become essential
18:51:32 <spwhitton> I think on the combination of my message and simon's
18:51:36 <bremner> I don't see a simple statement of that consensus
18:51:38 <spwhitton> (again, apologies it arived so late)
18:51:38 <bremner> oh.
18:51:43 <bremner> sorry, haven't read.
18:51:55 <Myon> (brb)
18:52:15 <smcv> I'll try to glue together what I said with spwhitton's response, and send the result to the public bug for further (public) discussion?
18:52:21 <spwhitton> smcv: I think that owuld be great
18:52:24 <gwolf> I have to go. Now that the kids have a RL school, it's up to me to bring them back home in time :-]
18:52:48 <marga> "the debianutils package must continue to provide which(1) and tempfile(1) (without a deprecation warning) until a     compatible utility is available in a package that is at least transitively essential in Debian 12." ?
18:52:50 <smcv> or if someone wants to take that from me, please do, since I'm aware I also need to be doing CFV on our other bug
18:52:50 <spwhitton> is there some way that we can start a vote sooner than next meeting, i.e., is there some way we can determine whether there is any disagreement on the public message simon is going to write?
18:53:01 <spwhitton> s/simon/someone/
18:53:37 <spwhitton> it's fresh in my mind so I can be the one to do it.
18:53:43 <bremner> well, we can follow up on the alias. I feel like I might be in the minority here in thinking people should fix their autopkgtests
18:53:55 <gwolf> spwhitton: Yes, lets try to vote before the next meeting!
18:54:01 <bremner> and that failing autopkgtests are less important than failing installs / builds
18:54:03 <smcv> arbitrary (short) deadline to call for vote
18:54:04 <marga> Yes, +1 to acting quickly on this.
18:54:06 <gwolf> bremner: a vote does not need to be unanymous FWIW
18:54:06 <smcv> perhaps/
18:54:08 <smcv> perhaps?
18:54:14 <gwolf> anyway, /me → afk now.
18:54:24 <spwhitton> yeah an action to cal a vote one week after that e-mail hits the bug, asuming no TC member says "wait a minute"
18:54:26 <ntyni> maybe 'in Debian 12 or later' ? otherwise if one doesn't materialize for the next release the text will be stale
18:54:39 <spwhitton> would that be okay?
18:54:58 <marga> Yeah
18:55:01 <ntyni> wfm
18:55:05 <spwhitton> okay, sec
18:55:06 <smcv> yes please
18:55:21 <smcv> we don't want this to drag on til the next meeting I think
18:55:22 <spwhitton> #action spwhitton to post combined mails to bug and CfV one week later if no sudden realisation of lack of consensus
18:55:28 <spwhitton> thanky ou everyone
18:55:32 <spwhitton> #topic Recruitment
18:55:46 <spwhitton> we have one candidate, two slots
18:56:05 <spwhitton> any thoughts on what we could do to improve this situation?
18:56:26 <bremner> clone the candidate?
18:56:38 <marga> Send out more emails?
18:56:58 <bremner> oh, more seriously, do both positions need to be filled at year end?
18:57:19 <spwhitton> bremner: no.  but it would be better to if we can.
18:57:26 <spwhitton> marga: I guess..
18:57:34 <spwhitton> marga: you mean to d-d-a?
18:57:44 <marga> Historically, we've taken quite some time to refill the positions.
18:57:50 <marga> spwhitton, yeah, and the scripty thing
18:58:34 <spwhitton> marga: script is firing happily once per month so far as I know.  are you suggesting we do some extra runs?
18:58:53 <ntyni> we had a d-d-a announcement just a month ago, another one now does not seem useful to me
18:58:59 <marga> yeah, maybe once per month is not enough
18:59:09 <marga> ntyni, you're right
18:59:30 <spwhitton> I can certainly increase the cron script frequency
18:59:31 <bremner> what about  some other kind of annoucement? Debian News or ??
18:59:34 <spwhitton> or the number of messages sent at once.
18:59:58 <spwhitton> we don't have much time, but maybe someone without any other AIs could investigate some other mediums.
19:00:17 <bremner> um. OK, since it was my idea, I can look into that.
19:00:24 <ntyni> https://wiki.debian.org/DeveloperNews could be one
19:00:26 <spwhitton> #action bremner to look into alternative ways to find candidates
19:00:40 <spwhitton> as it is now the hour:
19:00:43 <spwhitton> #topic Any Other Business
19:00:55 <spwhitton> anyone have anything?
19:00:59 <bremner> I think I won't make the next meeting, but I guess we will meet in december?
19:01:08 <bremner> so not yet my last TC meeting...
19:01:36 <spwhitton> bremner: okay thanks, perhaps you could confirm nearer the time so I can say "apologies received from"
19:01:43 <bremner> ack
19:01:50 <spwhitton> I won't #action you ;)
19:03:02 <spwhitton> alright
19:03:03 <spwhitton> #endmeeting