--- /dev/null
+18:59:26 <OdyX> #startmeeting
+18:59:26 <MeetBot> Meeting started Wed Aug 26 18:59:26 2015 UTC. The chair is OdyX. Information about MeetBot at http://wiki.debian.org/MeetBot.
+18:59:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+18:59:35 <OdyX> #topic Who is here?
+18:59:44 <OdyX> Didier Raboud
+18:59:59 <OdyX> #chair dondelelcaro
+18:59:59 <MeetBot> Current chairs: OdyX dondelelcaro
+19:00:06 * aba
+19:00:31 <hartmans> Sam hartman
+19:00:36 <dondelelcaro> Don ARmstrong
+19:00:56 <KGB-3> \ f\ 303Andreas Barth\ f \ 305master\ f 5429548 \ 306debian-ctte\ f \ 310636783_supermajority/intro\ f proper title for GR proposal
+19:00:59 <hartmans> My apologies for missing the bof.
+19:01:06 <OdyX> Same for me.
+19:01:10 <hartmans> I didn't track when it got rescheduled to.
+19:02:05 <OdyX> bdale, Mithrandir, vorlon, keithp: around ?
+19:02:34 <hartmans> I thought mithrandir gave regrets in IRC?
+19:02:37 <keithp> yup
+19:02:42 <OdyX> Let's wait 2-3 minutes more, I'm too swisso'clock.
+19:02:52 <OdyX> ah yeah, no Mithrandir
+19:04:09 <aba> while we wait I'd be happy to have review comments on 636783_supermajority/intro
+19:04:20 <aba> (quite short text)
+19:04:46 <bdale> I'm here, but multi-tasking (in a $dayjob call)
+19:05:03 <OdyX> I'm not too convinced that merging all 3 issues is worth the try though
+19:05:07 <OdyX> Anyway, let's start.
+19:05:11 <OdyX> #topic Next Meeting?
+19:05:28 <OdyX> dondelelcaro: where do we stand wrt next meeting ? I haven't followed up closely
+19:05:43 <dondelelcaro> Currently, this should be in the same time slot on the 30th of september
+19:05:44 <keithp> bdale: yeah, me too :-)
+19:05:53 <aba> won't work for me
+19:05:55 <dondelelcaro> I'll update the calendar with it shortly
+19:06:05 <aba> could we move it, best by at least 2 days (in either direction)
+19:06:08 <dondelelcaro> if anyone has a problem, please update the meeting vote script
+19:06:08 <aba> +?
+19:06:27 <OdyX> not 29 for me.
+19:06:36 <dondelelcaro> aba: I'll update the dates in the meeting vote script; if people can tweak their selection, that would be awesome
+19:06:45 <OdyX> #action everyone to update the script with its preferences.
+19:07:00 * dondelelcaro is going to have to head out, but will try to catch up later
+19:07:01 <aba> dondelelcaro: I try to find out how you did it afterwards, so I could do it next time myself
+19:07:20 <dondelelcaro> aba: oh, you just manually change it; it's a shell script which calls pocket devotee
+19:07:39 <OdyX> okay, let's iron the details through the repo.
+19:08:14 <OdyX> (please shout if I'm going too quickly through the points)
+19:08:17 <OdyX> #topic #741573 On menu systems
+19:08:23 * dondelelcaro is going to have to step out; I'll check in later.
+19:08:27 <aba> see you
+19:08:30 <OdyX> ++
+19:08:47 <aba> sune reviewed keithps proposal and considered it good (with a small change)
+19:09:12 <OdyX> Status is we got several feedbacks from Charles & Sune, which I think is mostly in agreement with keithp's proposal.
+19:09:17 <keithp> cool
+19:09:36 <OdyX> keithp: your input on some points in the thread would be welcome though.
+19:09:47 <hartmans> I still haven't seen an explanation of why Keith's proposal is better than option AB
+19:09:57 <OdyX> recomforting Charles on where yours come from.
+19:10:06 <hartmans> I really would like to see that as part of the ballot option.
+19:10:07 <KGB-3> \ f\ 303Andreas Barth\ f \ 305master\ f 8ae67d5 \ 306debian-ctte\ f \ 310meeting_poll/run_vote.sh\ f hope to have updated my preferences for sep meeting correctly (wed won't work)
+19:10:35 <OdyX> hartmans: for me, AB is a "pleases-them-all" solution, where keithp's is a better all-in-all solution, IMHO
+19:11:18 <OdyX> AB is the result of a complicated consensus and compromise process, but I think keithp's is a better technical solution
+19:11:28 <hartmans> Why?
+19:11:34 <keithp> hartmans: my proposal was a 'what I think the technical solution should be', while AB is a 'everyone agreed'
+19:11:39 <OdyX> hartmans: for me, keithp's has the net benefit of clearly phasing menu out.
+19:12:04 <hartmans> OK. but let's say that if we believe it.
+19:12:11 <keithp> hartmans: my proposal was to deprecate the existing menu system, not make them equal. essentially suggest that applications *not* provide menu files
+19:12:12 <OdyX> (it arguably puts the burden on "whoever cares about menu")
+19:12:27 <hartmans> I think it is really disrespectful to do something other than the agreement result without telling them why.
+19:12:50 <keithp> OdyX: really, what I want it to read as is asking the existing menu system to be able to parse .desktop files instead of using a different format for similar info
+19:12:59 <hartmans> And "this is better," seems incomplete to me. We're mature enough technologists that we ought to be able to enumerate the properties of a proposal that make it better.
+19:13:04 <aba> hartmans: disrespectful to whom?
+19:13:20 <hartmans> If it is that Keith's proposal phases out the menu format (or do you mean menu package), then let's actually say that.
+19:13:45 <hartmans> aba: those who participated in the process in debian-policy.
+19:13:47 <keithp> hartmans: agreed, any vote that includes my proposal should make the effect of that clear
+19:13:57 <OdyX> keithp: yes. The principal source of metadata becomes the .desktop files.
+19:14:12 <keithp> effectively deprecates the menu file format and pushes the menu packages to use .desktop file contents
+19:14:37 <hartmans> aba: For myself I've found it really is frustrating and demotivating to spend your energy towards something and have some other body come along and decide something else. That pain is much less when you can understand that your input was considered and understand why they choose differently.
+19:14:54 <keithp> hartmans: just to be clear, while I believe the proposal I wrote is a solid technical plan, I'm not at all opposed to a resolution that is softer than that and lets the project move in that direction more gradually
+19:15:02 <OdyX> hartmans: it's better because we decide on having one single source of metadata, instead of two.
+19:15:23 <hartmans> odyx: OK. But please say that in the ballot option.
+19:15:24 <keithp> OdyX: right, the question is whether to have the TC make that decision, or leave it up to the packagers
+19:15:50 <hartmans> Also, I'd like to draw attention to Charles's latest comment.
+19:15:53 <aba> hartmans: my understanding is also that e.g. Charles & Sune are participiants of the discussion, and if they like the outcome, I can't consider it unfriendly to them
+19:16:14 <aba> (otherwise, yes, I understand your motivation)
+19:16:15 <hartmans> He believes that Keith's proposal without a change to 9.6 to remove the recommendation that all command line utilities have a menu entry would be harmful.
+19:16:18 <OdyX> frankly, I don't believe that "leaving it to the packagers" will work.
+19:16:37 <hartmans> I think there's a lot to to that: I don't think we want desktop entries for command line stuff in the standard desktop menu.
+19:17:31 <OdyX> hartmans: yes, I was arguing that these two changes are orthogonal, and the TC decision shouldn't be understood as writing the actual "whether a menu/desktop should be provided" into stone.
+19:17:55 <hartmans> They clearly aren't orthogonal though.
+19:18:00 <OdyX> hartmans: actually, I think this part of the Policy is a) not enforced; b) outdated.
+19:18:09 <hartmans> I agree with you.
+19:18:15 <aba> and therefore ... c) irrelevant
+19:18:20 <OdyX> yes.
+19:18:39 <aba> otherwise, the question if two questions are orthogonal already set another decision on fire
+19:18:41 <hartmans> however, making the change away from menu format to desktop without relaxing that requirement gives us a very different policy than we have today.
+19:18:51 <OdyX> We could add to keithp's proposal a new point that voices the TC opinion in arguing that this should be changed.
+19:19:21 <aba> OdyX: or "we consider this to be changed unless the delegates decide otherwise"?
+19:19:22 <hartmans> You may believe that no one will actually do what policy says, but in general I'd prefer that we write a policy we'd be happy for people to follow.
+19:19:23 <keithp> hartmans: that almost seems like a bigger change than moving metadata formats
+19:19:32 <aba> hartmans: I agree with that
+19:19:41 <aba> (re "You may believe ...")
+19:20:01 <hartmans> keithp: It is.
+19:20:12 <hartmans> But option AB effectively accomplishes that change, where as your proposal does not.
+19:20:43 <hartmans> Because option AB doesn't apply the 9.6 language to the desktop format, only to the menu format, but relaxes the idea that we need menu entries.
+19:20:48 <OdyX> aba: I'd write something like "we recommend that this should be changed"
+19:20:56 <hartmans> But by combining formatis, you don't end up having that effect.
+19:21:09 <aba> keithp: what do you think about that?
+19:21:35 <keithp> aba: I think we've uncovered the kernel of the issue here, and that my proposal is almost a side issue
+19:22:27 <OdyX> keithp: would you be up (and have bandwidth) to enhance your proposal on this basis ?
+19:22:34 <keithp> and, I agree that package developers should make reasoned decisions about what to add to the desktop selection of applications
+19:23:13 <keithp> OdyX: it seems like a simple change, but I'm wondering now if we shouldn't resolve these issues separately
+19:23:16 <aba> if this is related enough that we care, we can we not fix it at the same moment?
+19:23:35 <aba> (perhaps also in two decisions?)
+19:23:36 <hartmans> So, I'd like to see this move forward soon. I think I could support a version's Keith's proposal that 1) explained the reason we prefer it is that we want one metadata format; 2) relaxed or recommended relaxing 9.6
+19:23:50 <OdyX> hartmans: one decision, or two decisions ?
+19:23:52 <hartmans> I'd be happy to help contribute text to such a ballot option if it would get us moving forward.
+19:24:43 <hartmans> I need to vote on them as one decision because I'd rank the options that change metadata format to .desktop but do not relax 9.6 much lower than others.
+19:25:09 <OdyX> Action: keithp & hartmans to work on this ?
+19:25:22 <hartmans> Actually, I could vote on 9.6 before the desktop becomes the format decision.
+19:25:48 <hartmans> Keith, would my help be useful/welcome?
+19:25:52 <OdyX> ah, that's an interesting idea.
+19:25:59 <keithp> OdyX: agreed. I can update my proposal to add the wording I had suggested about deciding when to make menu system entries based on expected usage patterns
+19:26:56 <OdyX> #action: keithp & hartmans to iron out a proposal also deciding upon §9.6's relevance
+19:26:59 <aba> sounds like we finally have progress.
+19:27:02 <aba> good, thanks.
+19:27:16 <OdyX> Yeah, Good to see this moving.
+19:27:17 <keithp> hartmans: let's do this today via email if we can
+19:27:29 <hartmans> Where is the current version of Keith's proposal/b allot option D
+19:28:00 <OdyX> 741573_menu_systems/odyx_draft.txt afaik
+19:28:09 <hartmans> ok, tnx
+19:28:16 <OdyX> #topic #771070 Coordinate plan and requirements for cross toolchain packages in Debian
+19:28:33 <hartmans> any progress at debconf?
+19:28:34 <OdyX> For info, vorlon attended the relevant part of the multiarch BoF, but isn't available right now.
+19:28:49 <aba> hartmans: AFAIUI yes, but I hoped for a more detailed report now
+19:29:21 <OdyX> same. Didn't have the courage to attend myself :/
+19:29:26 <aba> (or not so probably at next meeting or by mail)
+19:29:32 <OdyX> Anyway, I think we need vorlon's feedback.
+19:29:40 <hartmans> ok
+19:29:57 <OdyX> #action vorlon to report on his presence during the DebConf BoF
+19:30:11 <OdyX> #topic Constitutional change proposals
+19:30:19 <OdyX> #save
+19:30:23 <aba> we discussed about that at debconf, and considered it easier to propose it via normal process (in order to be able to accept amendments)
+19:30:27 <hartmans> aba: I read your intro and it seems reasonable.
+19:30:36 <aba> also I volunteered to do that
+19:30:47 <OdyX> I'm only not convinced that merging the 3 is the most efficient.
+19:30:48 <aba> (and we only pick the easier ones for now)
+19:31:06 <aba> OdyX: which ones should be part of the first GR?
+19:31:07 <hartmans> I think it will become obvious if merging is bad and we can unmerge at that point.
+19:31:09 <OdyX> That would be supermajority + numbering + discussion ?
+19:31:14 <aba> hartmans: sure.
+19:31:18 <aba> right
+19:31:34 <OdyX> supermajority + numbering, totally in favour of merging
+19:31:39 <aba> but I'm happy for any other combination if there is one which should be postponed, or be put into the first GR
+19:31:46 <OdyX> private-discussion might be picky
+19:31:59 <aba> in that case, I'd remove that one from the GR
+19:32:19 <OdyX> but I think we can try a common proposal, and split from then on in case of friction.
+19:32:53 <OdyX> okay, let's move on with this.
+19:33:04 <aba> ok.
+19:33:11 <OdyX> #action aba to proceed with combined GR with supermajority + numbering + private-discussion
+19:33:35 <aba> I'll send out the proposal now then, so please sponsor it soon then
+19:33:41 <OdyX> #topic #636783 Constitution: super-majority bug
+19:33:47 <OdyX> #topic #795854 Constitutional Amendment: Fix duplicate section numbering (A1)
+19:33:52 <OdyX> #topic #795859 Permit TC to hold private conversations
+19:34:06 <OdyX> Any comments on these three ?
+19:34:25 <hartmans> I don't know how I feel about private discussion GR.
+19:34:50 <hartmans> But it's not like we can't talk privately as individuals, so it's probably harmless
+19:35:03 <aba> I personally won't consider this one necessary but well
+19:35:45 <OdyX> do we need to decide this as TC, or can we iron this within the GR discussion ?
+19:35:58 <aba> I'd like to ask a question:
+19:36:07 <aba> anyone here who considers this change to be necessary?
+19:36:23 <aba> (I think Ian wasn't happy without the change)
+19:36:34 <aba> bdale: do you have any take about that specific change?
+19:36:45 <keithp> aba: the private conversation one?
+19:36:48 <aba> yes
+19:37:08 <aba> OdyX: if no one needs it I prefer to iron it out prior to the GR discussion :)
+19:37:12 <keithp> that was to address the need to talk to participants in an issue as the full ctte without needing those to be public
+19:38:10 <keithp> we can work without that, but there have been a few times where private conversations might have allowed for different communication contents, which may have made things easier overall.
+19:38:29 <OdyX> Hrm. I just re-read it, and it actually reads as a bigger constraint that without it.
+19:38:34 <keithp> especially where emotions are driving behavioru
+19:38:37 <aba> I don't think the constitution requires us to have all discussions public except formal resolutions but well.
+19:39:05 <keithp> aba: conventionally, we have done everything in public
+19:39:24 <aba> keithp: at least most, yes.
+19:39:37 <OdyX> I think the title and the amendment contradict eachother
+19:39:59 <aba> OdyX: yes, it should rather be "regulate the usage of private discussion"
+19:40:05 <aba> because that's what it's doing
+19:40:20 <OdyX> the amendment rather insists on limiting the use of private discussion
+19:40:36 <aba> of course if you limit that, it means that it is allowed.
+19:40:43 <aba> otherwise you don't need to limit it.
+19:40:46 <OdyX> yeah, right.
+19:40:48 <keithp> OdyX: the constitution does say that all discussions are to be public, except for appointments
+19:40:55 <aba> or "limit private discussion"
+19:41:35 <OdyX> keithp: right.
+19:41:44 <OdyX> I don't quite like the phrasing of the amendment.
+19:42:00 <aba> I'd say: this one isn't ready yet.
+19:42:17 <aba> so I think I'll remove it from the current proposal, and we need to fine-tune it.
+19:42:45 <OdyX> #action aba to proceed with combined GR with supermajority + numbering
+19:42:53 <OdyX> then ?
+19:43:28 <aba> #action aba to address different proposal for private discussions
+19:43:39 <OdyX> Cool, let's move on.
+19:44:03 <OdyX> #topic #795855 Formal cloture vote
+19:44:28 <aba> one question on the above:
+19:44:29 <hartmans> I'd like to find some other way to approach this.
+19:44:42 <hartmans> I understand the issue, and agree with vorlon that we need to do something here,
+19:44:45 <OdyX> While I sympathize with vorlon's concerns, this really feels like it will be limiting.
+19:44:49 <hartmans> but Ian's proposal is very heavy-handed.
+19:44:50 <aba> should I put in "there might be more issues coming up but these two are ready so we#d like to get them fixed now"?
+19:45:45 <aba> I had a discussion with bdale during IIRC lunch about this
+19:47:06 <OdyX> well, is there any action point we can hand out ? :)
+19:47:07 <bdale> sorry, I was 100% consumed my my work call, and now must go afk to get ready for a departing flight this afternoon. sorry I wasn't able to be more engaged, feel free to poke me in email for anything my personal input would be good on
+19:47:08 <aba> the outcome was rather like "we should have any option on that at least $num ctte members want to have as first priority" (whereas first priority means each of us could only force one option on)
+19:47:17 <aba> OdyX: sorry, typing too slow
+19:48:10 <hartmans> Why is it bad to have a whole bunch of options on the ballot if people really need them?
+19:48:20 <KGB-3> \ f\ 303Andreas Barth\ f \ 305master\ f 010af67 \ 306debian-ctte\ f \ 310636783_supermajority/intro\ f don't include the private discussions text into the first GR
+19:48:23 <hartmans> I realize it's a bit annoying, but what would break with a 20 option ballot?
+19:48:32 <OdyX> well, I really feel the situation from which these proposals came out was really special, and shouldn't be used as a generic argument for a failure of the constitution
+19:48:42 <aba> hartmans: technically condorcet might have an issue
+19:48:53 <hartmans> aba: in what way?
+19:49:27 <aba> OdyX: I think the constitution should basically say "in normal cases, we do it this way. If we are ever in such a special case again, these rules apply"
+19:49:27 <OdyX> hartmans: condorcet fails to be really relevant when n_options > n_participants.
+19:49:53 <hartmans> In what way?
+19:50:07 <aba> (and "this way" is we add as many options as people like, and can call for votes without any lead time but wait until everyone is ready)
+19:50:41 <OdyX> hartmans: tactical voting, etc.
+19:51:01 <hartmans> I'm sorry, I don't understand.
+19:51:43 <hartmans> I've seen a number of things described as tactical that in practice seem to be people expressing their honest preferences.
+19:51:57 <aba> hartmans: that too. Like for that special situation
+19:52:00 <hartmans> Especially with ranking things above and below FD.
+19:52:19 <bdale> my personal take is that condorcet is quite good at picking 1 of N choices on a single conceptual axis, but with a small voting population trying to answer 2 or more questions with a single ballot becomes wickedly confusing
+19:52:24 <keithp> hartmans: the appearance of tactical voting is a problem, and FD makes it possible
+19:53:11 <OdyX> hartmans: concretely, the convolution of orthogonal issues in the controversial systemd ballot would have made the result unreadable.
+19:53:40 <hartmans> odyx: We're not in agreement on that.
+19:53:52 <OdyX> hartmans: I know :)
+19:54:05 <hartmans> I've had experience with large ballots on IETF nomcom where we voted for entire slates.
+19:54:21 <bdale> the worst of the anxiety in the initsystem debate was I think very much mired in our internal disagreement about this issue
+19:54:26 <OdyX> I think we should really thrive to solve one issue per ballot, and not add administrativia overhead to avoid this.
+19:54:27 <hartmans> It took a while to get used to, but it seemed in that instance to work quite well, certainly better than any of the other alternatives.
+19:55:20 <aba> I think I'll propose a different solution to this one based on the discussions I had at debconf
+19:55:21 <OdyX> hartmans: concretely, weak vs strong coupling wasn't really a question that was asked to the TC, and there were several TC members not happy with having to decide this.
+19:55:22 <hartmans> I don't want to rat hole here, but I'm going to need significantly more than one sentence explanations to see the problem here. I will try to do my part to understand, but what I'm hearing sounds a lot like "trust us," and I have tried to think about this a fair bit and seem to be coming up with different conclusions.
+19:55:31 <hartmans> But this meeting is probably not the place to resolve that.
+19:55:34 <bdale> bottom line to me is that I'm not sure we really want or need a constitutional change here, because this is something that only came up once, and we all hated being in that position and don't want to do it again. but since my tenure on the board ends soon, I certainly won't stand in the way of others who think differently
+19:56:08 <hartmans> odyx: Yes, but there were some TC members who did want to link the issues.
+19:56:11 <aba> bdale: I tend to have it on the constitution as an exceptional rule, i.e. in normal times it doesn't prevent us to act as alwass
+19:56:24 <hartmans> You could have had a ballot with the four unlinked options and the linked options that seemed plausible.
+19:56:33 <hartmans> (I.E. no one was going to vote for tight openrc)
+19:57:02 <OdyX> hartmans: that's what I'm naming "tactical"
+19:57:31 <hartmans> That's not tactical: that's an honest difference of technical opinion.
+19:57:40 * aba agrees with hartmans on this
+19:57:43 <OdyX> hartmans: forcing a decision on coupling was (from a back-then outsider point of view) a way to make sure upstart would win.
+19:57:45 <bdale> I have to walk away now, for real, so I can't continue the discussion here and now... but hartmans, I'll be happy to chat with you about this some other time. I may in fact just be wrong, but based on what we went through for the initsystem debate, I have fairly strongly held opinions here
+19:57:56 <hartmans> O, forcing the decision was tactical.
+19:58:19 <hartmans> But it would not be tactical to have both linked and unlinked options on the ballot.
+19:58:25 <aba> OdyX: I disagree with that statement as well btw
+19:58:33 <bdale> I don't find the word "tactical" useful here, fwiw
+19:58:34 <hartmans> But it is tactical to manipulate the process to either get a purely linked or purely unlinked ballot.
+19:58:44 <OdyX> yeah, right, sorry for the choice of words.
+19:59:00 <aba> could we move on?
+19:59:09 <OdyX> Yes.
+19:59:19 <OdyX> I'm not going to push this, as I prefer status quo.
+19:59:37 <aba> so, I'd like to add another proposal that doesn't add bureacracy to the normal case
+19:59:39 <hartmans> I'm happy to move on
+19:59:46 <aba> however with low priority as other things are more urgent
+19:59:48 <aba> ok?
+20:00:05 <OdyX> yeah, more options can't hurt.
+20:00:13 <OdyX> #topic #795857 TC chair appointment
+20:00:49 <OdyX> On this front, I quite like bdale's proposal.
+20:01:03 * aba too
+20:01:18 <OdyX> it needs someone to produce a constitutional diff
+20:01:36 <aba> I'll do
+20:01:39 <aba> one question:
+20:02:17 <aba> I think the vote should start $time after the change in composition becomes effective, and also be coupled on the calendar
+20:02:46 <aba> reason for the second: then we don't need to stare at "when did the mail from the dpl appear"
+20:03:26 <aba> e.g. "it starts on the next 10th or 24th of the month after the change become effective" (ok, text should be written while I'm more awake)
+20:03:33 <aba> what do you think?
+20:03:38 <OdyX> again, I wouldn't add timing constraints, just something simple that says "a new TC chair appointment must happen after every TC composition change"
+20:03:39 <aba> or should we discuss that by mail?
+20:03:51 <aba> OdyX: ok, and any tc member could call on votes?
+20:04:11 <aba> (which would also de-couple from the exact dates which is relevant to me)
+20:04:30 <OdyX> aba: timing constraints are going to hurt, one time or another
+20:04:49 <aba> sure, I think your proposal is better
+20:05:00 <OdyX> add a "before the TC can take decisions" if that really need to be enforced
+20:05:22 <OdyX> #Move this to list ?
+20:06:01 <aba> so some text like "Anytime the composition changes there should be a vote on the chair, any TC member can call for votes on that. If a call for votes on the chair is called, for any other not yet decided resolution the new chair has the cast vote"
+20:06:06 <aba> but yes
+20:06:12 <OdyX> #action aba to draft a constitutional diff imposing a TC chair appointment after every TC composition change"
+20:06:23 <OdyX> #topic Additional Business
+20:06:51 <aba> I heared we have something else coming up
+20:06:56 <OdyX> ah
+20:07:18 <OdyX> public enough ?
+20:07:27 <aba> someone told me that systemd/packagekit does automatic system updates, and maintainers considers it a feature
+20:07:40 <aba> otherwise I think we should wait till the bug arrives at us
+20:07:45 <OdyX> there was a chat on this on debian-devel.
+20:08:01 <OdyX> Last I understood, this was still under heavy discussion.
+20:08:01 <hartmans> *why* o*why* is systemd part of that.
+20:08:07 <hartmans> :-)
+20:08:12 <aba> well, I had "as tc member you should know about because ..."
+20:08:15 <aba> we'll see
+20:08:31 <aba> another thing, we had the ask the ctte bof at debconf
+20:08:38 <aba> which I think was fairly good (again)
+20:09:39 <hartmans> anything come up there that should be brought to a brooader audience?
+20:09:40 <OdyX> yes. Sorry for having missed the rescheduling
+20:10:09 <KGB-3> \ f\ 303Andreas Barth\ f \ 305master\ f 955ff7d \ 306debian-ctte\ f \ 310636783_supermajority/intro\ f wording fix
+20:10:40 <aba> hartmans: not really
+20:10:53 <hartmans> tnx
+20:10:56 <aba> I think it was quite interessting for those asking us
+20:11:04 <aba> to get an better understanding how the ctte works
+20:11:11 <aba> well, hm. there is something.
+20:11:29 <aba> we also told people that we have the change to re-allocate two seats soon
+20:11:39 <aba> so this is something we also should start to work on here
+20:12:33 <OdyX> ah yeah, right. We should have a private repo for candidates and their statuses?
+20:12:34 <aba> i.e. I think we should do an call for volunteers sooner than later (however I think it would be good if Don would do it)
+20:12:53 <aba> I didn't think we ever had. We just had a status mail IIRC
+20:12:59 <OdyX> okay, works too.
+20:13:13 <aba> I think we should put in the minutes that we need to work on it
+20:13:24 <aba> and anyone who would like to could create a draft for d-d-a
+20:13:32 <OdyX> #info We should really start working on the two seats renewals.
+20:13:44 <OdyX> I'll try to see if I can draft something.
+20:13:51 <OdyX> #action OdyX to take a look
+20:13:55 <OdyX> Anthing else ?
+20:13:56 <aba> constitution doesn't force us to have more than six people but I think it would be good
+20:14:04 <OdyX> Yes.
+20:14:06 <aba> and I just sent the GR proposal out
+20:14:22 <OdyX> Cool, thanks
+20:14:26 <OdyX> #save
+20:14:35 <aba> otherwise for me I think we're done
+20:14:44 <OdyX> Great. Thanks for the lively discussion.
+20:14:56 <OdyX> #endmeeting
\ No newline at end of file
projects / debian-ctte.git / commitdiff