Add council meeting summary/log 20160911

Signed-off-by: Justin Lecher <jlec@gentoo.org>

1 files changed, 369 insertions, 0 deletions

diff --git a/meeting-logs/20160911.txt b/meeting-logs/20160911.txt
new file mode 100644
index 0000000..5ff45d5
--- /dev/null
+++ b/meeting-logs/20160911.txt
@@ -0,0 +1,369 @@
+[21:01:08] <willikins> K_F: (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
+[21:01:11] <K_F> roll call
+[21:01:11] <crankyrubian> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
+[21:01:12] * K_F here
+[21:01:17] <jlec> blueness dilfridge jlec K_F rich0 ulm WilliamH ping
+[21:01:26] * rich0 here
+[21:01:26] * WilliamH here
+[21:01:30] * jlec here
+[21:02:04] <jlec> dilfridge there?
+[21:02:17] <K_F> whose bot is crankyrubian ?
+[21:02:19] <jlec> Anybody proxying blueness ?
+[21:02:37] <jlec> no idea?
+[21:02:44] *** K_F sets mode: +q crankyrubian!*@*
+[21:02:48] <rich0> My guess is not, since his absence was last-minute
+[21:03:12] <jlec> WilliamH ping
+[21:03:17] * WilliamH is here
+[21:03:26] <dilfridge> here
+[21:03:28] <jlec> ulm said he will be late
+[21:03:50] * ulm here
+[21:03:51] <dilfridge> dont know of anyone proxying blueness
+[21:04:10] <WilliamH> dilfridge: I think blueness' issue was last minute.
+[21:04:23] <jlec> 2) RFC: Eclasses and EAPI[0]
+[21:04:34] <jlec> https://archives.gentoo.org/gentoo-dev/message/87e630b9da724c5c59060608aba596a9
+[21:04:54] <WilliamH> I don't think there's anything for us to do there; it is a qa issue.
+[21:04:54] <jlec> K_F: you brought this up.
+[21:05:02] <jlec> Can you go ahead here?
+[21:05:06] <K_F> jlec: sure
+[21:05:24] <K_F> jlec: I believe most of the discussion has taken place on the ML thread already, but the tl;dr is:
+[21:06:34] <K_F> eclass maintainer is in a better situation to consider whether the eclass is appropriate for an EAPI bump. Explicit definition improves compatibility and removes uncertainty amongst developers not that familiar with the eclasses to consider whether it has been upgraded, which might fail in subtle (or not so much), ways
+[21:07:16] <WilliamH> K_F: right. see line 29 of systemd.eclass as an example
+[21:07:47] <K_F> now, the negative comments I've seen is mostly using specific functions before porting the full eclass
+[21:07:52] <rich0> FWIW, I think it is a great idea
+[21:08:04] <ulm> I don't think that there should be any EAPI conditionals for eclasses in the package manager
+[21:08:15] * WilliamH agrees with ulm
+[21:08:25] <K_F> ulm: indeed, the proposal is for in-eclass test for EAPI
+[21:08:45] <WilliamH> K_F: a number of eclasses already do it.
+[21:08:48] <ulm> and befaore we would do that, we would have to disentangle eclasses and eclass libraries
+[21:09:03] <ulm> the latter being largely independent of EAPI
+[21:09:13] <K_F> ulm: can you elaborate a bit on that?
+[21:09:14] <dilfridge> it works perfectly fine by testing inside the eclass
+[21:09:37] <K_F> ulm: are you talking the in-eclass case, or possible PMS change now
+[21:09:45] <ulm> K_F: some eclasses just provide utility functions, these are the one I call eclass libs
+[21:09:51] <ulm> e.g. versionator.eclass
+[21:10:01] <dilfridge> I suppose ulm means something like perl-modules.eclass (with phase functions) and perl-functions.eclass (which provides utility functions)
+[21:10:04] <K_F> ulm: I don't see why they shouldn't be treated the same in EAPI case question
+[21:10:15] <jlec> me neither
+[21:10:19] <K_F> ulm: although adding support for new EAPI in those cases should likely be easier
+[21:10:20] <WilliamH> same here.
+[21:10:30] <dilfridge> it's true that the utilities are easier to port and test, but the basic problem is the same
+[21:10:32] <jlec> I think explicit stating compatibility is a good thing
+[21:11:03] <jlec> Same as blocking multiple sourcing. But that's another story
+[21:11:08] <ulm> when there's nothing EAPI dependent then there's no need for a conditional :)
+[21:11:17] *** Joins: rich0_ (~quassel@gentoo/developer/rich0)
+[21:11:17] *** ChanServ sets mode: +o rich0_
+[21:11:23] <WilliamH> ulm: that's true too.
+[21:11:30] <jlec> The question is, is this something we need to enforce or should we rather suggest QA come up with something first?
+[21:11:39] <dilfridge> ulm: do you know that a future eapi won't change that?
+[21:11:47] *** stanley is now known as sam_c
+[21:12:03] <ulm> dilfridge: like using something other than bash?
+[21:12:07] <K_F> jlec: I'm not aware of an explicit policy on it at the time being
+[21:12:21] <WilliamH> dilfridge: no, but  we don't know that it will either.
+[21:12:26] <dilfridge> heh, not that extreme, but...
+[21:12:30] <K_F> jlec: but you're proposing we ask qa to come up with one?
+[21:12:42] *** Quits: rich0 (~quassel@gentoo/developer/rich0) (Ping timeout: 244 seconds)
+[21:12:47] <dilfridge> https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/systemd.eclass#n29
+[21:13:01] *** rich0_ is now known as rich0
+[21:13:06] <rich0> sorry, freenode server went down I think
+[21:13:07] <dilfridge> ^ we can always just recommend that this block goes everywhere if there's not something similar already
+[21:13:26] <dilfridge> if the eclass is trivial, the block is trivial to extend
+[21:13:27] <K_F> dilfridge: yup, that is what is proposed
+[21:13:52] <jlec> K_F: In the end it is a qa thing. They should come up with a way of enforcing it or not. We can ultimately vote on that
+[21:14:11] <K_F> jlec: ah, re enforcement, yes, I agree, that is qa
+[21:14:12] <WilliamH> Again though, I'm not sure it is necessary if the eclass doesn't contain anything that is eapi dependent.
+[21:14:13] <jlec> dilfridge: makes sense.
+[21:14:26] * WilliamH thinks it should be left to the maintainers
+[21:14:36] <jlec> WilliamH: you don't know if that changes for newer eclasses.
+[21:14:38] * ulm agrees with WilliamH
+[21:14:39] <jlec> eh
+[21:14:41] <jlec> EAPI
+[21:14:41] <WilliamH> They will know best whether their eclasses contain eapi dependent code.
+[21:14:53] <K_F> WilliamH: a consistent policy helps other developers
+[21:14:56] <jlec> EAPI also means bash versions eg
+[21:15:12] <jlec> there you might come into strange problems
+[21:15:18] <K_F> WilliamH: and you don't really know if something breaks down the road in the environment (such as bash version backwards incompatibility)
+[21:15:36] <ulm> jlec: if you argue along these lines then you cannot guarantee that even the EAPI test will work
+[21:15:41] <jlec> Better explicitly state compatibility instead of waiting if it might break 
+[21:15:49] <ulm> because sourcing of the eclass may already fail
+[21:16:05] * WilliamH agrees with ulm, leave it to maintainers.
+[21:16:07] <jlec> yeah sure
+[21:16:24] <jlec> so we should better encode the EAPI in the extension 
+[21:16:25] *** sam_c is now known as cmpct
+[21:16:30] <jlec> :D
+[21:16:31] <dilfridge> so let's not try to solve all eclass problems and world peace in one go
+[21:16:36] <rich0> HOw will they know if anything is EAPI-dependent?
+[21:16:40] <rich0> Since future EAPIs aren't written
+[21:16:52] <K_F> WilliamH: the issue is we're leaving it to the wrong maintainers, now package maintainers needs to review it and consider it, instead of eclass maintainers having to mark it explicitly
+[21:16:54] * WilliamH sigh
+[21:16:55] *** Quits: cmpct (~stanley@unaffiliated/stanley) (Changing host)
+[21:16:55] *** Joins: cmpct (~stanley@unaffiliated/cmpct)
+[21:16:58] * jlec agrees with rich0 here
+[21:17:01] <rich0> I'm in favor of requiring all eclasses die by default
+[21:17:22] * WilliamH is against it
+[21:17:31] <jlec> Should we vote on something here today?
+[21:17:38] <WilliamH> no
+[21:17:44] <dilfridge> I suppose we want to vote at most on a "recommendation", right?
+[21:17:47] *** cmpct is now known as sam_c
+[21:17:48] <K_F> jlec: it depends on whether we feel the topic is sufficiently discussed
+[21:17:52] <dilfridge> Not on a "requirement"?
+[21:17:54] <jlec> yes recommandation
+[21:18:02] <dilfridge> then it really doesnt matter
+[21:18:08] <K_F> dilfridge: that might make it more difficult for qa to have a policy
+[21:18:13] <dilfridge> because in the end it's down to qa and maintainer
+[21:18:18] <rich0> If PMS every breaks sourcing compatibility then that would have to be built into PMS anyway.  That's an old discussion
+[21:18:25] <dilfridge> well qa can always set policies if they want
+[21:18:42] <dilfridge> it's not as if any qa policy has to be decided by the council beforehand
+[21:18:53] <jlec> Did we saw significant breakage because of this? If not, I think QA should officially approach us for the vote if they see need to enforce it.
+[21:19:15] * WilliamH agrees, I haven't seen any major breakage over this
+[21:19:17] <rich0> Ultimately it is up to package maintainers to determine if the eclass they use works with the EAPI they use.
+[21:19:27] <rich0> How many maintainers actually read the eclass source to check?
+[21:19:30] <rich0> They just assume it works.
+[21:19:32] <K_F> jlec: most recently get_libdir for EAPI 6, but the issue is it stops gating forward upgrades that might put restrictions on what changes can be done in EAPIs
+[21:19:34] <rich0> As they should.
+[21:19:47] <K_F> rich0: exactly
+[21:19:48] <rich0> The issue is subtle breakage, not failure to ever build.
+[21:20:11] <rich0> Thats why you always version ABIs.
+[21:20:23] * WilliamH isn't interested in any requirements at the council level for this.
+[21:20:40] <ulm> I'm against fixing things that aren't broken
+[21:20:46] <K_F> it is broken
+[21:20:50] <rich0> I'm not necessarily looking for a decision here.  In any case, QA has my endorsement if they want to make this happen.
+[21:21:04] <jlec> mine too
+[21:21:13] <K_F> and we're putting unnecessary responsibility on package maintainers to need to review every eclass they try to use
+[21:21:22] <jlec> !proj qa
+[21:21:23] <willikins> jlec: (qa@gentoo.org) creffett, mgorny, mrueg, patrick, pinkbyte, tommy, ulm, williamh, zerochaos, zlogene
+[21:21:25] <K_F> and understand the ramifications
+[21:21:32] <jlec> Please give this a thought
+[21:22:14] <jlec> We mostly leave it to you and will continue the discussion in case you officially approach us
+[21:22:30] <WilliamH> K_F: So what about the defacto requirements to use eclasses for certain things?
+[21:22:40] <K_F> WilliamH: such as?
+[21:22:56] <ulm> the problem with EAPI 6 was rather that it took considerable time until the major eclasses gained support
+[21:23:05] <ulm> but not major breakage
+[21:23:37] <K_F> ulm: that depends on the changes that are being done, though
+[21:23:49] <rich0> Probably because breakage was obvious enough to be noticed by maintainers
+[21:24:04] <rich0> It isn't major breakage that is the issue, but intermittent / minor stuff
+[21:24:10] * WilliamH is not going to support a blanket requirement for eclasses.
+[21:25:06] <jlec> Any more need for discussion now?
+[21:25:06] <WilliamH> Unless maintainers have the option of moving away from eclasses when they lag behind with adding the new eapi
+[21:25:32] <K_F> WilliamH: there is no requirement to use eclasses per se, but I fail to see what issue you're trying to address
+[21:25:38] <rich0> If an eclass actually works with a more recent eapi they can just update the test.
+[21:25:48] <K_F> the ultimate goal is a stable, productive end-user environment
+[21:25:51] <rich0> If it doesn't work, then they shouldn't be using it, test or not.
+[21:26:16] <rich0> Just right now we blame individual package maintainers for not doing code review on every eclass they use.
+[21:27:49] <ulm> that EAPI test block is the de-facto standard in any case
+[21:27:54] <ulm> which doesn't mean that we must add it to all eclasses, even if they're shell function libraries effectively
+[21:28:14] <WilliamH> K_F: No there's not, but you would get dinged for example if you wrote your own python ebuild without the eclasses.
+[21:28:16] <K_F> ulm: it being a de-facto standard should only be an argument to make it de jure
+[21:28:46] <ulm> K_F: yeah, where it makes sense
+[21:28:48] <WilliamH> If I rewrote the pybugz ebuild to not respect the python eclasses I would probably get called out by qa.
+[21:29:46] <WilliamH> Or if I wrote a gnome-based ebuild that did not use their eclasses...
+[21:29:57] <K_F> ulm: if only functionality, shouldn't updating the catch block be trivial so it is a moot issue ?
+[21:30:24] <K_F> i.e it won't keep updates back in practice, just requires the eclass maintainer to state that it will work for new EAPI anyways
+[21:31:03] <WilliamH> Actually there's a problem with that eapi test in systemd thinking about it.
+[21:31:22] <WilliamH> line 29 should just say case "$EAPI" in
+[21:31:32] <WilliamH> or maybe even
+[21:31:35] <WilliamH> case $EAPI in
+[21:31:50] <WilliamH> but that's a side note to this discussion I guess.
+[21:32:12] <ulm> hm? ${EAPI:-0} is the standard expression there
+[21:32:25] <ulm> because "0" and "" are equivalent
+[21:32:27] <WilliamH> ulm: eapi could be a string.
+[21:32:46] <WilliamH> ulm: EAPI=my-cool-eapi
+[21:32:47] <K_F> WilliamH: ?
+[21:32:49] <jlec> No need for the :-0
+[21:32:57] <jlec> because "" would match *
+[21:32:59] <ulm> WilliamH: yes, but why would that be a problem
+[21:33:15] <WilliamH> EAPI=my-cool-eapi
+[21:33:23] <WilliamH> EAPI=more-cool-stuff
+[21:33:35] <WilliamH> would both be m in that expression
+[21:34:03] <ulm> `${PARAMETER:-WORD}'   If PARAMETER is unset or null, the expansion of WORD is substituted.  Otherwise, the value of PARAMETER is substituted.
+[21:34:21] <WilliamH> ah ok... nvm
+[21:34:21] <K_F> WilliamH: its a default assignment
+[21:34:40] <jlec> Are we good here?
+[21:34:52] <WilliamH> yes, I guess, I don't support a hard requirement though.
+[21:35:11] <jlec> 3) Bugs with council participation[1]
+[21:35:11] <jlec> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3253044&query_format=advanced
+[21:35:17] <rich0> I think we're all on record :)
+[21:35:35] <K_F> jlec: you'll have to write the summary for it, so up to you I guess.
+[21:36:24] <jlec> K_F: "There were discussion, but no agreement. Generally no requirement for actions."
+[21:36:26] <jlec> :)
+[21:36:46] <WilliamH> jlec: lgtm
+[21:36:52] <K_F> we don't know if there is agreement without a vote
+[21:36:57] <jlec> dilfridge: summaries?
+[21:37:06] <dilfridge> yeah I know...
+[21:37:16] <jlec> K_F: the tendency was 50:50
+[21:37:19] <dilfridge> one is still missing I think
+[21:37:51] <K_F> bug 571490
+[21:37:54] <willikins> K_F: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council
+[21:38:09] <jlec> Any actions to take on the games team bugs? I cannot remember what we decided last time.
+[21:38:44] <ulm> kill games.eclass with fire, IIRC
+[21:38:53] <rich0> Yup, anybody who wants to can do it.
+[21:39:04] <rich0> Just need somebody who cares enough to do it.  :)
+[21:39:10] <WilliamH> Yes, and it is being worked on iirc
+[21:39:10] <jlec> Okay, so it is up to the community
+[21:39:14] <jlec> bug 590972
+[21:39:16] <willikins> jlec: https://bugs.gentoo.org/590972 "repoman should prevent people from adding a new package with a metadata.xml pointing to maintained-needed directly"; Portage Development, Repoman; CONF; pacho:dev-portage
+[21:39:36] <jlec> Done from our side, up to the PM maintainers 
+[21:39:41] <WilliamH> Right.
+[21:39:42] <jlec> agreed?
+[21:39:48] <ulm> yes
+[21:39:48] <K_F> jlec: yeah, done from our side
+[21:40:08] <dilfridge> yes
+[21:40:22] <jlec> Where are we with the changelogs?
+[21:40:27] <jlec> bug 565566
+[21:40:29] <willikins> jlec: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
+[21:40:30] <WilliamH> Waiting for infra
+[21:40:36] <dilfridge> well, waiting for infra
+[21:40:44] <dilfridge> infra is waiting for something not entirely related
+[21:40:53] <WilliamH> Right.
+[21:41:00] <jlec> Should we take actions here?
+[21:41:05] <jlec> Or just ping them again?
+[21:41:33] <WilliamH> The only action we can take is tell them that what they are waiting for is unrelated and ask them to remove the changelogs.
+[21:41:39] <dilfridge> well we could ask them to just drop the changelogs, while keeping working on the separate repo for them
+[21:41:56] <ulm> the two actions we decided on in the April meeting can be taken immediately
+[21:41:59] * WilliamH thinks we should
+[21:42:11] <ulm> and the separate rsync module can be provided later
+[21:42:29] <K_F> ulm: agreed
+[21:42:32] <dilfridge> ++
+[21:42:33] <jlec> Okay, I will add something to the bug
+[21:42:45] <jlec> 4) Open floor
+[21:42:46] <ulm> whenever where will be the perfect cvs-git conversion (TM)
+[21:42:47] <dilfridge> should we reinforce it with a vote?
+[21:42:56] * WilliamH thinks so
+[21:43:13] <ulm> +1
+[21:43:13] <jlec> Would that change something?
+[21:43:23] <K_F> dilfridge: as in council requesting infra to remove changelogs specificially
+[21:43:23] <dilfridge> it would reinforce our viewpoint
+[21:43:24] <jlec> at least we reacted
+[21:43:46] <jlec> Let me quickly read the points ulm referred to
+[21:43:53] <ulm> https://bugs.gentoo.org/show_bug.cgi?id=565566#c10
+[21:44:07] * WilliamH reads
+[21:44:34] <K_F> dilfridge: as a procedural point, any issue that should be voted on should likely be part of the regular agenda
+[21:44:45] <dilfridge> council requests infra to drop changelogs from rsync and not wait for a good cvs-to-git conversion first
+[21:44:52] <dilfridge> it is on the regular agenda
+[21:45:24] <ulm> dilfridge: or alternatively, change their ordering to newest first
+[21:45:50] <ulm> but yes, it will be more likely dropping them
+[21:46:02] <dilfridge> wfm, but I fear even if that works, we will end up dropping them due to file size at some poing
+[21:46:08] <jlec> I would rather go for, 
+[21:46:08] <dilfridge> pint
+[21:46:12] <dilfridge> point
+[21:46:41] <WilliamH> We said we were going to kill changelogs in a meeting long before the conversion, so they should be dropped.
+[21:46:44] * dilfridge hopes this helps infra to get the manifest issues under control
+[21:47:15] <K_F> dilfridge: I don't see how it would be related to that
+[21:47:37] <WilliamH> K_F: it is a bug assigned to us, so it is part of the agenda that way.
+[21:47:47] <jlec> The council request infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering without any further delays.
+[21:48:07] <WilliamH> jlec: wait a sec, there is another meeting where we said just drop them.
+[21:48:19] <WilliamH> jlec: an older meeting
+[21:48:27] <WilliamH> jlec: it was unanimous back then.
+[21:48:42] <dilfridge> K_F: it should simplify the git-to-rsync conversion
+[21:48:50] <ulm> WilliamH: we wanted to drop them in rsync
+[21:49:00] <jlec> Then take that one. I think back referring and explicitly asking for action is better
+[21:49:09] <WilliamH> wait a sec let me find it.
+[21:49:20] <ulm> WilliamH: that doesn't prevent anyone from providing generated ChangeLogs elsewhere
+[21:49:24] <K_F> dilfridge: yes, but the issues we've been having have been related to other issues as far as I'm aware, mostly related to developer time and use of mtime on staging area
+[21:49:29] <K_F> dilfridge: not a bottleneck issue per se
+[21:49:53] <WilliamH> ulm: no, it doesn't that is the separate project infra wants to do.
+[21:50:37] <jlec> There are summaries missing for meetings
+[21:50:45] <jlec> June and July
+[21:50:53] <ulm> WilliamH: 20141014 meeting
+[21:51:05] <jlec> ulm your meetings
+[21:51:05] <ulm> "do we need to continue to create new ChangeLog entries once we're operating in git?"
+[21:51:08] <dilfridge> sigh... so far noone really managed to explain to me what the real problem is (since git usually does not do any mtime fiddling, so rsync should figure out which files changed just fine...)
+[21:51:09] <ulm> No: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
+[21:51:16] <jlec> and blueness
+[21:51:38] <K_F> dilfridge: not if you don't do checksum verification of files but simple method
+[21:51:48] <K_F> dilfridge: that for large scale rollouts makes sense
+[21:52:15] <K_F> due to resource considerations
+[21:52:16] <dilfridge> K_F: that makes no sense
+[21:52:29] <dilfridge> even without checksums, file changed -> newer mtime -> transfer
+[21:52:32] <rich0> I switched to git syncing ages ago...
+[21:52:48] <rich0> It seems silly that we refer people to use rsync and then have it break randomly though...
+[21:53:07] <prometheanfire> git won't scale to all our users though (to my knowlege)
+[21:53:15] <dilfridge> git afaik does not touch mtime. so file changed -> newer mtime somewhere when git working tree is modified -> rsync finds modified file
+[21:53:15] <jlec> Let's focus on the ChangeLog vote please
+[21:53:17] <K_F> dilfridge: not if it changes to a mtime in the past
+[21:53:20] <rich0> prometheanfire: just mirror it
+[21:53:29] <rich0> And I'm sure github or whatever can handle our user base.
+[21:53:52] <dilfridge> K_F: git does not touch mtime. the kernel does when git modifies the file. and then it depends on the clock of the infra box, not on commit etc
+[21:53:54] <prometheanfire> rich0: is git signing verification done?
+[21:53:55] <K_F> rich0: you have issues with OpenPGP verification if switching user base to git as well
+[21:54:07] <prometheanfire> that's why I'm still on webrsync
+[21:54:18] <rich0> I'm not sure what verification git does by default.
+[21:54:19] <K_F> as it will need to match individual developer signatures and not release engineering keys that is signing it in staging area
+[21:54:31] <prometheanfire> K_F: ++
+[21:54:32] <K_F> which causes issues for revocation and developer retirement
+[21:54:43] <rich0> Beyond the, ugh, sha1s
+[21:54:44] <dilfridge> K_F: so that process should be completely independent of commit times and signature times. why it is is a big mystery.
+[21:55:00] <jlec> hello
+[21:55:04] <jlec> ChangeLogs
+[21:55:08] <dilfridge> :)
+[21:55:15] * dilfridge says drop'em
+[21:55:23] <jlec> What do we like to vote on?
+[21:55:25] * dilfridge gets a drink
+[21:55:32] * prometheanfire wants to drop them
+[21:55:35] * WilliamH says drop'em
+[21:55:40] <prometheanfire> iirc, infra side they've just been a pain
+[21:55:44] <ulm> yes, drop them
+[21:55:52] <prometheanfire> but I don't get a vote :D
+[21:55:54] <rich0> I think I'm already on record back when dberkholz was still on council :)
+[21:56:10] <WilliamH> Drop the changelogs from rsync.
+[21:56:50] <jlec> The council requests infra to respect multiple votes to drop ChangeLogs and act without any further delay.
+[21:56:58] <jlec> Does that work?
+[21:57:01] <K_F> no
+[21:57:16] <K_F> the requests have given the ability to drop,not been a requirement to drop
+[21:57:34] <leio> They provide actual user value that you can't get easily (like emerge --changelog easily if it weren't broken) without using git, and we don't advertise git as the thing to use for that in any way (yet); I don't get a vote either.
+[21:57:49] <K_F> the vote we have from 20160410 is that "If ChangeLog files are provided, they must be in the order of
+[21:57:52] <K_F>   newest entries first"
+[21:58:19] <jlec> K_F: Please suggest something to vote on.
+[21:58:51] <K_F> jlec: I don't like voting on things not in the scheduled agenda as a matter of principe :)
+[21:58:57] <ulm> jlec: I think your wording from above (19:47) was just fine
+[21:59:09] <WilliamH> repaste that again please?
+[21:59:14] <WilliamH> re-paste *
+[21:59:28] <K_F> but yeah, the former one should be ok
+[21:59:32] <jlec> The council request infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering without any further delays.
+[21:59:45] <rich0> I suggest we talk to them before we toss edicts at them.
+[21:59:51] <K_F> but I'm not sure if that requires a vote to begin with
+[21:59:59] <K_F> as it is referring to a vote on subject already had
+[22:00:15] <dilfridge> The council asks infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering
+[22:00:16] <rich0> Why not just start a dicussion, email/etc?
+[22:00:21] <K_F> so yeah, that sounds like starting a discussion
+[22:00:38] <ulm> rich0: well, there was no reply to my pinging them on the bug
+[22:00:38] <rich0> In general we try not to dictate that people work on things.
+[22:00:50] * WilliamH agrees with rich0
+[22:00:59] <rich0> Do we really think voting on it will change anything, besides ticking people off?
+[22:00:59] <dilfridge> how much work is dropping them?
+[22:01:02] <WilliamH> I think the problem is, there has been no status or update in a long time.
+[22:01:09] <rich0> Well, dock their pay then!
+[22:01:17] <dilfridge> hrhr
+[22:01:28] <ulm> *sigh*
+[22:01:31] <WilliamH> dilfridge: heh, that's part of the problem, we don't know.
+[22:02:03] <rich0> In any case, I think we're all aligned on what the preferred solution is, and that we need to see what can be done to move it along.
+[22:02:18] <prometheanfire> well, I wasn't aware we needed to do anything (infra)
+[22:02:18] <WilliamH> I don't want to wait another 10 years for it to be fixed. :p
+[22:02:21] <rich0> I don't think we need more resolutions.  Does somebody want to volunteer to contact them?
+[22:02:36] <dilfridge> You just volunteered. :P
+[22:02:43] <leio> Having them in wrong order is more value than not having them (can still tail them, plus there were portage patches to figure out --changelog in that order, maybe even included), except for those that don't want the rsync traffic for them (for which a separate changelog rsync "overlay" has been mentioned as a future possibility)
+[22:02:47] <WilliamH> I think we should also try to figure out why we can't move everyone to git syncing.
+[22:03:06] <dilfridge> leio: the other related problem is that file sizes are now exploding
+[22:03:07] <rich0> Yeah, I just volunteered for the last take the lead task.  :)
+[22:03:08] <prometheanfire> imho, use git if you want changelogs
+[22:03:17] <rich0> I think that satisfies my obligation for a while.  :)
+[22:03:20] <K_F> WilliamH: I provided some rationale for that above for OpenPGP signatures
+[22:03:20] <leio> that's a separate problem with an easy technical solution.
+[22:03:22] <jlec> good, so let's reschedule until next meeting and wait what comes out of the ping
+[22:03:34] <dilfridge> rich0: point taken, and I feel with you.
+[22:03:43] <leio> (per-year ChangeLogs; dropping some years old at some point if needed)
+[22:04:01] <jlec> rich0++
+[22:04:30] <prometheanfire> so, are people ok if we (infra) start working on removing changelogs from rsync/git?
+[22:04:39] <prometheanfire> is that the ask?
+[22:04:45] <K_F> prometheanfire: yes, that is clear in 20160410 summary
+[22:04:47] <dilfridge> I think from council, yes
+[22:04:53] <ulm> +1
+[22:04:54] <prometheanfire> k
+[22:05:06] <jlec> So now
+[22:05:07] <jlec> 4) Open floor
+[22:05:14] <prometheanfire> I'll bug robbat2 or myself to work on it
+[22:05:22] <K_F> prometheanfire: https://bugs.gentoo.org/show_bug.cgi?id=565566#c10 (1st vote)
+[22:05:24] <jlec> Community, anything you like to bring forward?
+[22:07:47] <jlec> If there is nothing, I will close the meeting for today
+[22:07:55] <jlec> Thanks for participating.
+[22:08:27] <ulm> jlec: thank you for chairing
+[22:08:46] <jlec> I am sorry for being so pushy. :)