2016-09-11 00:27:39-!- mode/#gentoo-council [+o rich0] by ChanServ
2016-09-11 07:49:33-!- Irssi: #gentoo-council: Total of 45 nicks [7 ops, 0 halfops, 0 voices, 38 normal]
2016-09-11 07:49:33-!- mode/#gentoo-council [+o K_F] by ChanServ
2016-09-11 07:49:33-!- Irssi: Join to #gentoo-council was synced in 0 secs
2016-09-11 11:48:28-!- mode/#gentoo-council [+o blueness] by ChanServ
2016-09-11 18:59:34<@ulm> I may be a few minutes late for the meeting
2016-09-11 19:08:04<@jlec> okay
2016-09-11 19:17:14<@dilfridge|mobile> It's so quiet...
2016-09-11 19:18:40 * K_F finds The Improbability of Love to be a surprisingly funny novel
2016-09-11 19:19:06<@K_F> but a group of people is about to get signed OpenPGP keys as well, yay
2016-09-11 19:20:18 * dilfridge|mobile sitting in cafe proofreading 20 pages of bibliography
2016-09-11 19:38:54<@blueness> oh damn i have to go to canada in about 30 mins
2016-09-11 19:38:56<@blueness> i’m going to have to miss the meeting
2016-09-11 19:38:57<@blueness> my mom needs some help
2016-09-11 19:38:58<@blueness> i live in buffalo and she lives in niagara falls ON on the other side of the boarder
2016-09-11 19:38:59<@blueness> can someone cover for me - sorry for the last minute
2016-09-11 19:39:40-!- Irssi: #gentoo-council: Total of 45 nicks [8 ops, 0 halfops, 0 voices, 37 normal]
2016-09-11 20:54:06 * WilliamH is here
2016-09-11 20:55:19 * jlec as well
2016-09-11 21:00:34 * rich0 glances at watch :)
2016-09-11 21:00:44<@jlec> Hi
2016-09-11 21:00:56<@jlec> everyone around?
2016-09-11 21:01:08<@K_F> !proj council
2016-09-11 21:01:09< willikins> K_F: (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
2016-09-11 21:01:11<@K_F> roll call
2016-09-11 21:01:12< crankyrubian> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
2016-09-11 21:01:12 * K_F here
2016-09-11 21:01:17<@jlec> blueness dilfridge jlec K_F rich0 ulm WilliamH ping
2016-09-11 21:01:26 * rich0 here
2016-09-11 21:01:26 * WilliamH here
2016-09-11 21:01:30 * jlec here
2016-09-11 21:02:05<@jlec> dilfridge there?
2016-09-11 21:02:17<@K_F> whose bot is crankyrubian ?
2016-09-11 21:02:19<@jlec> Anybody proxying blueness ?
2016-09-11 21:02:37<@jlec> no idea?
2016-09-11 21:02:44-!- mode/#gentoo-council [+q crankyrubian!*@*] by K_F
2016-09-11 21:02:48<@rich0> My guess is not, since his absence was last-minute
2016-09-11 21:03:12<@jlec> WilliamH ping
2016-09-11 21:03:17 * WilliamH is here
2016-09-11 21:03:26<@dilfridge> here
2016-09-11 21:03:28<@jlec> ulm said he will be late
2016-09-11 21:03:50 * ulm here
2016-09-11 21:03:51<@dilfridge> dont know of anyone proxying blueness
2016-09-11 21:04:10<@WilliamH> dilfridge: I think blueness' issue was last minute.
2016-09-11 21:04:23<@jlec> 2) RFC: Eclasses and EAPI[0]
2016-09-11 21:04:34<@jlec> https://archives.gentoo.org/gentoo-dev/message/87e630b9da724c5c59060608aba596a9
2016-09-11 21:04:54<@WilliamH> I don't think there's anything for us to do there; it is a qa issue.
2016-09-11 21:04:54<@jlec> K_F: you brought this up.
2016-09-11 21:05:02<@jlec> Can you go ahead here?
2016-09-11 21:05:06<@K_F> jlec: sure
2016-09-11 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:
2016-09-11 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
2016-09-11 21:07:16<@WilliamH> K_F: right. see line 29 of systemd.eclass as an example
2016-09-11 21:07:47<@K_F> now, the negative comments I've seen is mostly using specific functions before porting the full eclass
2016-09-11 21:07:52<@rich0> FWIW, I think it is a great idea
2016-09-11 21:08:04<@ulm> I don't think that there should be any EAPI conditionals for eclasses in the package manager
2016-09-11 21:08:15 * WilliamH agrees with ulm
2016-09-11 21:08:25<@K_F> ulm: indeed, the proposal is for in-eclass test for EAPI
2016-09-11 21:08:46<@WilliamH> K_F: a number of eclasses already do it.
2016-09-11 21:08:48<@ulm> and befaore we would do that, we would have to disentangle eclasses and eclass libraries
2016-09-11 21:09:03<@ulm> the latter being largely independent of EAPI
2016-09-11 21:09:13<@K_F> ulm: can you elaborate a bit on that?
2016-09-11 21:09:14<@dilfridge> it works perfectly fine by testing inside the eclass
2016-09-11 21:09:37<@K_F> ulm: are you talking the in-eclass case, or possible PMS change now
2016-09-11 21:09:45<@ulm> K_F: some eclasses just provide utility functions, these are the one I call eclass libs
2016-09-11 21:09:51<@ulm> e.g. versionator.eclass
2016-09-11 21:10:01<@dilfridge> I suppose ulm means something like perl-modules.eclass (with phase functions) and perl-functions.eclass (which provides utility functions)
2016-09-11 21:10:04<@K_F> ulm: I don't see why they shouldn't be treated the same in EAPI case question
2016-09-11 21:10:15<@jlec> me neither
2016-09-11 21:10:19<@K_F> ulm: although adding support for new EAPI in those cases should likely be easier
2016-09-11 21:10:20<@WilliamH> same here.
2016-09-11 21:10:30<@dilfridge> it's true that the utilities are easier to port and test, but the basic problem is the same
2016-09-11 21:10:32<@jlec> I think explicit stating compatibility is a good thing
2016-09-11 21:11:03<@jlec> Same as blocking multiple sourcing. But that's another story
2016-09-11 21:11:08<@ulm> when there's nothing EAPI dependent then there's no need for a conditional :)
2016-09-11 21:11:20-!- mode/#gentoo-council [+o rich0_] by ChanServ
2016-09-11 21:11:23<@WilliamH> ulm: that's true too.
2016-09-11 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?
2016-09-11 21:11:39<@dilfridge> ulm: do you know that a future eapi won't change that?
2016-09-11 21:12:03<@ulm> dilfridge: like using something other than bash?
2016-09-11 21:12:07<@K_F> jlec: I'm not aware of an explicit policy on it at the time being
2016-09-11 21:12:21<@WilliamH> dilfridge: no, but  we don't know that it will either.
2016-09-11 21:12:27<@dilfridge> heh, not that extreme, but...
2016-09-11 21:12:30<@K_F> jlec: but you're proposing we ask qa to come up with one?
2016-09-11 21:12:47<@dilfridge> https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/systemd.eclass#n29
2016-09-11 21:13:06<@rich0> sorry, freenode server went down I think
2016-09-11 21:13:07<@dilfridge> ^ we can always just recommend that this block goes everywhere if there's not something similar already
2016-09-11 21:13:26<@dilfridge> if the eclass is trivial, the block is trivial to extend
2016-09-11 21:13:27<@K_F> dilfridge: yup, that is what is proposed 
2016-09-11 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
2016-09-11 21:14:11<@K_F> jlec: ah, re enforcement, yes, I agree, that is qa
2016-09-11 21:14:12<@WilliamH> Again though, I'm not sure it is necessary if the eclass doesn't contain anything that is eapi dependent.
2016-09-11 21:14:13<@jlec> dilfridge: makes sense.
2016-09-11 21:14:26 * WilliamH thinks it should be left to the maintainers
2016-09-11 21:14:36<@jlec> WilliamH: you don't know if that changes for newer eclasses.
2016-09-11 21:14:38 * ulm agrees with WilliamH
2016-09-11 21:14:39<@jlec> eh
2016-09-11 21:14:41<@jlec> EAPI
2016-09-11 21:14:41<@WilliamH> They will know best whether their eclasses contain eapi dependent code.
2016-09-11 21:14:53<@K_F> WilliamH: a consistent policy helps other developers 
2016-09-11 21:14:57<@jlec> EAPI also means bash versions eg
2016-09-11 21:15:12<@jlec> there you might come into strange problems
2016-09-11 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)
2016-09-11 21:15:37<@ulm> jlec: if you argue along these lines then you cannot guarantee that even the EAPI test will work
2016-09-11 21:15:41<@jlec> Better explicitly state compatibility instead of waiting if it might break
2016-09-11 21:15:49<@ulm> because sourcing of the eclass may already fail
2016-09-11 21:16:05 * WilliamH agrees with ulm, leave it to maintainers.
2016-09-11 21:16:08<@jlec> yeah sure
2016-09-11 21:16:24<@jlec> so we should better encode the EAPI in the extension
2016-09-11 21:16:30<@jlec> :D
2016-09-11 21:16:31<@dilfridge> so let's not try to solve all eclass problems and world peace in one go
2016-09-11 21:16:36<@rich0> HOw will they know if anything is EAPI-dependent?
2016-09-11 21:16:40<@rich0> Since future EAPIs aren't written
2016-09-11 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
2016-09-11 21:16:54 * WilliamH sigh
2016-09-11 21:16:58 * jlec agrees with rich0 here
2016-09-11 21:17:01<@rich0> I'm in favor of requiring all eclasses die by default
2016-09-11 21:17:22 * WilliamH is against it
2016-09-11 21:17:31<@jlec> Should we vote on something here today?
2016-09-11 21:17:38<@WilliamH> no
2016-09-11 21:17:44<@dilfridge> I suppose we want to vote at most on a "recommendation", right?
2016-09-11 21:17:48<@K_F> jlec: it depends on whether we feel the topic is sufficiently discussed
2016-09-11 21:17:52<@dilfridge> Not on a "requirement"?
2016-09-11 21:17:54<@jlec> yes recommandation
2016-09-11 21:18:02<@dilfridge> then it really doesnt matter
2016-09-11 21:18:08<@K_F> dilfridge: that might make it more difficult for qa to have a policy
2016-09-11 21:18:13<@dilfridge> because in the end it's down to qa and maintainer
2016-09-11 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
2016-09-11 21:18:25<@dilfridge> well qa can always set policies if they want
2016-09-11 21:18:42<@dilfridge> it's not as if any qa policy has to be decided by the council beforehand
2016-09-11 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.
2016-09-11 21:19:15 * WilliamH agrees, I haven't seen any major breakage over this
2016-09-11 21:19:17<@rich0> Ultimately it is up to package maintainers to determine if the eclass they use works with the EAPI they use.
2016-09-11 21:19:27<@rich0> How many maintainers actually read the eclass source to check?
2016-09-11 21:19:30<@rich0> They just assume it works.
2016-09-11 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
2016-09-11 21:19:34<@rich0> As they should.
2016-09-11 21:19:47<@K_F> rich0: exactly
2016-09-11 21:19:48<@rich0> The issue is subtle breakage, not failure to ever build.
2016-09-11 21:20:11<@rich0> Thats why you always version ABIs.
2016-09-11 21:20:23 * WilliamH isn't interested in any requirements at the council level for this.
2016-09-11 21:20:40<@ulm> I'm against fixing things that aren't broken
2016-09-11 21:20:46<@K_F> it is broken
2016-09-11 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.
2016-09-11 21:21:04<@jlec> mine too
2016-09-11 21:21:13<@K_F> and we're putting unnecessary responsibility on package maintainers to need to review every eclass they try to use
2016-09-11 21:21:22<@jlec> !proj qa
2016-09-11 21:21:23< willikins> jlec: (qa@gentoo.org) creffett, mgorny, mrueg, patrick, pinkbyte, tommy, ulm, williamh, zerochaos, zlogene
2016-09-11 21:21:25<@K_F> and understand the ramifications
2016-09-11 21:21:32<@jlec> Please give this a thought
2016-09-11 21:22:14<@jlec> We mostly leave it to you and will continue the discussion in case you officially approach us
2016-09-11 21:22:30<@WilliamH> K_F: So what about the defacto requirements to use eclasses for certain things?
2016-09-11 21:22:39<@K_F> WilliamH: such as?
2016-09-11 21:22:56<@ulm> the problem with EAPI 6 was rather that it took considerable time until the major eclasses gained support
2016-09-11 21:23:05<@ulm> but not major breakage
2016-09-11 21:23:37<@K_F> ulm: that depends on the changes that are being done, though
2016-09-11 21:23:49<@rich0> Probably because breakage was obvious enough to be noticed by maintainers
2016-09-11 21:24:04<@rich0> It isn't major breakage that is the issue, but intermittent / minor stuff
2016-09-11 21:24:10 * WilliamH is not going to support a blanket requirement for eclasses.
2016-09-11 21:25:06<@jlec> Any more need for discussion now?
2016-09-11 21:25:06<@WilliamH> Unless maintainers have the option of moving away from eclasses when they lag behind with adding the new eapi
2016-09-11 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
2016-09-11 21:25:38<@rich0> If an eclass actually works with a more recent eapi they can just update the test.
2016-09-11 21:25:48<@K_F> the ultimate goal is a stable, productive end-user environment
2016-09-11 21:25:51<@rich0> If it doesn't work, then they shouldn't be using it, test or not.
2016-09-11 21:26:16<@rich0> Just right now we blame individual package maintainers for not doing code review on every eclass they use.
2016-09-11 21:27:49<@ulm> that EAPI test block is the de-facto standard in any case
2016-09-11 21:27:54<@ulm> which doesn't mean that we must add it to all eclasses, even if they're shell function libraries effectively
2016-09-11 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.
2016-09-11 21:28:16<@K_F> ulm: it being a de-facto standard should only be an argument to make it de jure
2016-09-11 21:28:46<@ulm> K_F: yeah, where it makes sense
2016-09-11 21:28:48<@WilliamH> If I rewrote the pybugz ebuild to not respect the python eclasses I would probably get called out by qa.
2016-09-11 21:29:46<@WilliamH> Or if I wrote a gnome-based ebuild that did not use their eclasses...
2016-09-11 21:29:57<@K_F> ulm: if only functionality, shouldn't updating the catch block be trivial so it is a moot issue ?
2016-09-11 21:30:23<@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
2016-09-11 21:31:03<@WilliamH> Actually there's a problem with that eapi test in systemd thinking about it.
2016-09-11 21:31:22<@WilliamH> line 29 should just say case "$EAPI" in
2016-09-11 21:31:32<@WilliamH> or maybe even
2016-09-11 21:31:36<@WilliamH> case $EAPI in
2016-09-11 21:31:50<@WilliamH> but that's a side note to this discussion I guess.
2016-09-11 21:32:12<@ulm> hm? ${EAPI:-0} is the standard expression there
2016-09-11 21:32:25<@ulm> because "0" and "" are equivalent
2016-09-11 21:32:27<@WilliamH> ulm: eapi could be a string.
2016-09-11 21:32:46<@WilliamH> ulm: EAPI=my-cool-eapi
2016-09-11 21:32:46<@K_F> WilliamH: ?
2016-09-11 21:32:49<@jlec> No need for the :-0
2016-09-11 21:32:57<@jlec> because "" would match *
2016-09-11 21:33:00<@ulm> WilliamH: yes, but why would that be a problem
2016-09-11 21:33:15<@WilliamH> EAPI=my-cool-eapi
2016-09-11 21:33:23<@WilliamH> EAPI=more-cool-stuff
2016-09-11 21:33:35<@WilliamH> would both be m in that expression
2016-09-11 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.
2016-09-11 21:34:21<@WilliamH> ah ok... nvm
2016-09-11 21:34:21<@K_F> WilliamH: its a default assignment
2016-09-11 21:34:40<@jlec> Are we good here?
2016-09-11 21:34:52<@WilliamH> yes, I guess, I don't support a hard requirement though.
2016-09-11 21:35:11<@jlec> 3) Bugs with council participation[1]
2016-09-11 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
2016-09-11 21:35:18<@rich0> I think we're all on record :)
2016-09-11 21:35:35<@K_F> jlec: you'll have to write the summary for it, so up to you I guess.
2016-09-11 21:36:24<@jlec> K_F: "There were discussion, but no agreement. Generally no requirement for actions."
2016-09-11 21:36:26<@jlec> :)
2016-09-11 21:36:46<@WilliamH> jlec: lgtm
2016-09-11 21:36:52<@K_F> we don't know if there is agreement without a vote
2016-09-11 21:36:57<@jlec> dilfridge: summaries?
2016-09-11 21:37:06<@dilfridge> yeah I know...
2016-09-11 21:37:17<@jlec> K_F: the tendency was 50:50
2016-09-11 21:37:19<@dilfridge> one is still missing I think
2016-09-11 21:37:51<@K_F> bug 571490
2016-09-11 21:37:54< willikins> K_F: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council
2016-09-11 21:38:09<@jlec> Any actions to take on the games team bugs? I cannot remember what we decided last time.
2016-09-11 21:38:44<@ulm> kill games.eclass with fire, IIRC
2016-09-11 21:38:53<@rich0> Yup, anybody who wants to can do it.
2016-09-11 21:39:04<@rich0> Just need somebody who cares enough to do it.  :)
2016-09-11 21:39:10<@WilliamH> Yes, and it is being worked on iirc
2016-09-11 21:39:10<@jlec> Okay, so it is up to the community
2016-09-11 21:39:14<@jlec> bug 590972
2016-09-11 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
2016-09-11 21:39:36<@jlec> Done from our side, up to the PM maintainers
2016-09-11 21:39:41<@WilliamH> Right.
2016-09-11 21:39:42<@jlec> agreed?
2016-09-11 21:39:48<@ulm> yes
2016-09-11 21:39:48<@K_F> jlec: yeah, done from our side
2016-09-11 21:40:08<@dilfridge> yes
2016-09-11 21:40:22<@jlec> Where are we with the changelogs?
2016-09-11 21:40:27<@jlec> bug 565566
2016-09-11 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
2016-09-11 21:40:30<@WilliamH> Waiting for infra
2016-09-11 21:40:36<@dilfridge> well, waiting for infra
2016-09-11 21:40:44<@dilfridge> infra is waiting for something not entirely related
2016-09-11 21:40:53<@WilliamH> Right.
2016-09-11 21:41:00<@jlec> Should we take actions here?
2016-09-11 21:41:05<@jlec> Or just ping them again?
2016-09-11 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.
2016-09-11 21:41:39<@dilfridge> well we could ask them to just drop the changelogs, while keeping working on the separate repo for them
2016-09-11 21:41:56<@ulm> the two actions we decided on in the April meeting can be taken immediately
2016-09-11 21:42:00 * WilliamH thinks we should
2016-09-11 21:42:11<@ulm> and the separate rsync module can be provided later
2016-09-11 21:42:29<@K_F> ulm: agreed
2016-09-11 21:42:32<@dilfridge> ++
2016-09-11 21:42:34<@jlec> Okay, I will add something to the bug
2016-09-11 21:42:45<@jlec> 4) Open floor
2016-09-11 21:42:46<@ulm> whenever where will be the perfect cvs-git conversion (TM)
2016-09-11 21:42:48<@dilfridge> should we reinforce it with a vote?
2016-09-11 21:42:56 * WilliamH thinks so
2016-09-11 21:43:13<@ulm> +1
2016-09-11 21:43:13<@jlec> Would that change something?
2016-09-11 21:43:23<@K_F> dilfridge: as in council requesting infra to remove changelogs specificially
2016-09-11 21:43:23<@dilfridge> it would reinforce our viewpoint
2016-09-11 21:43:24<@jlec> at least we reacted
2016-09-11 21:43:46<@jlec> Let me quickly read the points ulm referred to
2016-09-11 21:43:53<@ulm> https://bugs.gentoo.org/show_bug.cgi?id=565566#c10
2016-09-11 21:44:07 * WilliamH reads
2016-09-11 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
2016-09-11 21:44:45<@dilfridge> council requests infra to drop changelogs from rsync and not wait for a good cvs-to-git conversion first
2016-09-11 21:44:52<@dilfridge> it is on the regular agenda
2016-09-11 21:45:25<@ulm> dilfridge: or alternatively, change their ordering to newest first
2016-09-11 21:45:50<@ulm> but yes, it will be more likely dropping them
2016-09-11 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
2016-09-11 21:46:08<@jlec> I would rather go for,
2016-09-11 21:46:08<@dilfridge> pint
2016-09-11 21:46:12<@dilfridge> point
2016-09-11 21:46:41<@WilliamH> We said we were going to kill changelogs in a meeting long before the conversion, so they should be dropped.
2016-09-11 21:46:44 * dilfridge hopes this helps infra to get the manifest issues under control
2016-09-11 21:47:15<@K_F> dilfridge: I don't see how it would be related to that
2016-09-11 21:47:37<@WilliamH> K_F: it is a bug assigned to us, so it is part of the agenda that way.
2016-09-11 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.
2016-09-11 21:48:07<@WilliamH> jlec: wait a sec, there is another meeting where we said just drop them.
2016-09-11 21:48:19<@WilliamH> jlec: an older meeting
2016-09-11 21:48:27<@WilliamH> jlec: it was unanimous back then.
2016-09-11 21:48:42<@dilfridge> K_F: it should simplify the git-to-rsync conversion
2016-09-11 21:48:50<@ulm> WilliamH: we wanted to drop them in rsync
2016-09-11 21:49:00<@jlec> Then take that one. I think back referring and explicitly asking for action is better
2016-09-11 21:49:09<@WilliamH> wait a sec let me find it.
2016-09-11 21:49:20<@ulm> WilliamH: that doesn't prevent anyone from providing generated ChangeLogs elsewhere
2016-09-11 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
2016-09-11 21:49:29<@K_F> dilfridge: not a bottleneck issue per se
2016-09-11 21:49:53<@WilliamH> ulm: no, it doesn't that is the separate project infra wants to do.
2016-09-11 21:50:37<@jlec> There are summaries missing for meetings
2016-09-11 21:50:46<@jlec> June and July
2016-09-11 21:50:53<@ulm> WilliamH: 20141014 meeting
2016-09-11 21:51:05<@jlec> ulm your meetings
2016-09-11 21:51:05<@ulm> "do we need to continue to create new ChangeLog entries once we're operating in git?"
2016-09-11 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...)
2016-09-11 21:51:09<@ulm> No: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
2016-09-11 21:51:16<@jlec> and blueness
2016-09-11 21:51:38<@K_F> dilfridge: not if you don't do checksum verification of files but simple method
2016-09-11 21:51:48<@K_F> dilfridge: that for large scale rollouts makes sense
2016-09-11 21:52:15<@K_F> due to resource considerations
2016-09-11 21:52:16<@dilfridge> K_F: that makes no sense
2016-09-11 21:52:29<@dilfridge> even without checksums, file changed -> newer mtime -> transfer
2016-09-11 21:52:32<@rich0> I switched to git syncing ages ago...
2016-09-11 21:52:48<@rich0> It seems silly that we refer people to use rsync and then have it break randomly though...
2016-09-11 21:53:07< prometheanfire> git won't scale to all our users though (to my knowlege)
2016-09-11 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
2016-09-11 21:53:15<@jlec> Let's focus on the ChangeLog vote please
2016-09-11 21:53:17<@K_F> dilfridge: not if it changes to a mtime in the past
2016-09-11 21:53:20<@rich0> prometheanfire: just mirror it
2016-09-11 21:53:29<@rich0> And I'm sure github or whatever can handle our user base.
2016-09-11 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
2016-09-11 21:53:54< prometheanfire> rich0: is git signing verification done?
2016-09-11 21:53:55<@K_F> rich0: you have issues with OpenPGP verification if switching user base to git as well
2016-09-11 21:54:07< prometheanfire> that's why I'm still on webrsync
2016-09-11 21:54:18<@rich0> I'm not sure what verification git does by default.
2016-09-11 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
2016-09-11 21:54:31< prometheanfire> K_F: ++
2016-09-11 21:54:32<@K_F> which causes issues for revocation and developer retirement
2016-09-11 21:54:43<@rich0> Beyond the, ugh, sha1s
2016-09-11 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.
2016-09-11 21:55:00<@jlec> hello
2016-09-11 21:55:04<@jlec> ChangeLogs
2016-09-11 21:55:08<@dilfridge> :)
2016-09-11 21:55:15 * dilfridge says drop'em
2016-09-11 21:55:23<@jlec> What do we like to vote on?
2016-09-11 21:55:25 * dilfridge gets a drink
2016-09-11 21:55:32 * prometheanfire wants to drop them
2016-09-11 21:55:35 * WilliamH says drop'em
2016-09-11 21:55:40< prometheanfire> iirc, infra side they've just been a pain
2016-09-11 21:55:44<@ulm> yes, drop them
2016-09-11 21:55:52< prometheanfire> but I don't get a vote :D
2016-09-11 21:55:54<@rich0> I think I'm already on record back when dberkholz was still on council :)
2016-09-11 21:56:10<@WilliamH> Drop the changelogs from rsync.
2016-09-11 21:56:50<@jlec> The council requests infra to respect multiple votes to drop ChangeLogs and act without any further delay.
2016-09-11 21:56:58<@jlec> Does that work?
2016-09-11 21:57:01<@K_F> no
2016-09-11 21:57:16<@K_F> the requests have given the ability to drop,not been a requirement to drop
2016-09-11 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.
2016-09-11 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
2016-09-11 21:57:50<@K_F>   newest entries first"
2016-09-11 21:58:19<@jlec> K_F: Please suggest something to vote on.
2016-09-11 21:58:51<@K_F> jlec: I don't like voting on things not in the scheduled agenda as a matter of principe :)
2016-09-11 21:58:57<@ulm> jlec: I think your wording from above (19:47) was just fine
2016-09-11 21:59:10<@WilliamH> repaste that again please?
2016-09-11 21:59:14<@WilliamH> re-paste *
2016-09-11 21:59:28<@K_F> but yeah, the former one should be ok
2016-09-11 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.
2016-09-11 21:59:45<@rich0> I suggest we talk to them before we toss edicts at them.
2016-09-11 21:59:51<@K_F> but I'm not sure if that requires a vote to begin with
2016-09-11 21:59:59<@K_F> as it is referring to a vote on subject already had
2016-09-11 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
2016-09-11 22:00:16<@rich0> Why not just start a dicussion, email/etc?
2016-09-11 22:00:21<@K_F> so yeah, that sounds like starting a discussion
2016-09-11 22:00:38<@ulm> rich0: well, there was no reply to my pinging them on the bug
2016-09-11 22:00:38<@rich0> In general we try not to dictate that people work on things.
2016-09-11 22:00:50 * WilliamH agrees with rich0
2016-09-11 22:00:59<@rich0> Do we really think voting on it will change anything, besides ticking people off?
2016-09-11 22:00:59<@dilfridge> how much work is dropping them?
2016-09-11 22:01:02<@WilliamH> I think the problem is, there has been no status or update in a long time.
2016-09-11 22:01:09<@rich0> Well, dock their pay then!
2016-09-11 22:01:17<@dilfridge> hrhr
2016-09-11 22:01:28<@ulm> sigh
2016-09-11 22:01:31<@WilliamH> dilfridge: heh, that's part of the problem, we don't know.
2016-09-11 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.
2016-09-11 22:02:18< prometheanfire> well, I wasn't aware we needed to do anything (infra)
2016-09-11 22:02:18<@WilliamH> I don't want to wait another 10 years for it to be fixed. :p
2016-09-11 22:02:21<@rich0> I don't think we need more resolutions.  Does somebody want to volunteer to contact them?
2016-09-11 22:02:36<@dilfridge> You just volunteered. :P
2016-09-11 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)
2016-09-11 22:02:47<@WilliamH> I think we should also try to figure out why we can't move everyone to git syncing.
2016-09-11 22:03:06<@dilfridge> leio: the other related problem is that file sizes are now exploding
2016-09-11 22:03:07<@rich0> Yeah, I just volunteered for the last take the lead task.  :)
2016-09-11 22:03:08< prometheanfire> imho, use git if you want changelogs
2016-09-11 22:03:17<@rich0> I think that satisfies my obligation for a while.  :)
2016-09-11 22:03:20<@K_F> WilliamH: I provided some rationale for that above for OpenPGP signatures
2016-09-11 22:03:20< leio> that's a separate problem with an easy technical solution.
2016-09-11 22:03:22<@jlec> good, so let's reschedule until next meeting and wait what comes out of the ping
2016-09-11 22:03:34<@dilfridge> rich0: point taken, and I feel with you.
2016-09-11 22:03:43< leio> (per-year ChangeLogs; dropping some years old at some point if needed)
2016-09-11 22:04:01<@jlec> rich0++
2016-09-11 22:04:30< prometheanfire> so, are people ok if we (infra) start working on removing changelogs from rsync/git?
2016-09-11 22:04:39< prometheanfire> is that the ask?
2016-09-11 22:04:45<@K_F> prometheanfire: yes, that is clear in 20160410 summary
2016-09-11 22:04:47<@dilfridge> I think from council, yes
2016-09-11 22:04:53<@ulm> +1
2016-09-11 22:04:54< prometheanfire> k
2016-09-11 22:05:06<@jlec> So now
2016-09-11 22:05:07<@jlec> 4) Open floor
2016-09-11 22:05:15< prometheanfire> I'll bug robbat2 or myself to work on it
2016-09-11 22:05:22<@K_F> prometheanfire: https://bugs.gentoo.org/show_bug.cgi?id=565566#c10 (1st vote)
2016-09-11 22:05:24<@jlec> Community, anything you like to bring forward?
2016-09-11 22:07:47<@jlec> If there is nothing, I will close the meeting for today
2016-09-11 22:07:55<@jlec> Thanks for participating.
2016-09-11 22:08:27<@ulm> jlec: thank you for chairing
2016-09-11 22:08:46<@jlec> I am sorry for being so pushy. :)
2016-09-11 22:09:22-!- ulm changed the topic of #gentoo-council to: Next meeting: 2016-10-09 19:00 UTC | http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161009T19 | https://wiki.gentoo.org/wiki/Project:Council
2016-09-11 22:09:28< Soap___> oh soz
2016-09-11 22:09:29< leio> I understood it was already open floor before, which is why I dared to speak up in defense of keeping changelogs easily available to our users :D
2016-09-11 22:09:31< Soap___> I had one more thing
2016-09-11 22:10:06< Soap___> can I still voice my request?
2016-09-11 22:10:41< prometheanfire> Soap___: don't ask to ask, but not sure of the results
2016-09-11 22:11:08< Soap___> so my request was, whether it would be possible to also get the ALLARCHES policy for KEYWORDREQ too?
2016-09-11 22:11:16<@jlec> Soap___: go ahead
2016-09-11 22:11:20< Soap___> if we have pure python packages for instance
2016-09-11 22:11:31< Soap___> why not have ALLARCHES for KEYWORDREQ too?
2016-09-11 22:11:41<@jlec> Soap___: makes sense to me
2016-09-11 22:11:47<@jlec> !proj council
2016-09-11 22:11:48< willikins> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh
2016-09-11 22:11:54< prometheanfire> Soap___: I'm not sure I like it
2016-09-11 22:11:58<@K_F> Soap___: I'm not sure if that makes sense
2016-09-11 22:12:02<@jlec> Please give some quick thoughts on this?
2016-09-11 22:12:04<@ulm> Soap___: that's something to discuss in the -dev ML
2016-09-11 22:12:21< prometheanfire> Soap___: I understand the desire, allarches for keyword req could be a suggestion to the the arch teams
2016-09-11 22:12:26< prometheanfire> a hit that this is simpler
2016-09-11 22:12:26< leio> ALLARCHES STABLEREQ applies to stuff that has an older revision/version already stable on that arch
2016-09-11 22:12:43<@K_F> leio: exactly
2016-09-11 22:12:46< prometheanfire> yarp
2016-09-11 22:12:51< prometheanfire> a hint
2016-09-11 22:13:05< leio> for KEYWORDREQ that would mean introducing a new keyword for the arch to begin with, in most cases
2016-09-11 22:13:14< Soap___> leio: I thought ALLARCHES was just that if one got stablised, so could the others, without any preconditions
2016-09-11 22:13:16<@jlec> Soap___: I think I have seen the discussion before.
2016-09-11 22:13:34<@dilfridge> I see how it would be useful, but I'm not sure arches will like it or think that it makes sense
2016-09-11 22:13:40<@WilliamH> Is a pure script package really likely to not run on one arch if it runs on another?
2016-09-11 22:13:48< Soap___> WilliamH: thats my rationale
2016-09-11 22:13:52<@jlec> Soap___: please raise the discussion on the ml and make sure it is on the agenda next time
2016-09-11 22:13:54< leio> Soap___: that only makes sense when applied to cases where an older version of that packge is already stable on the arch in question.
2016-09-11 22:14:05<@dilfridge> Soap___: how about, propose it on the ML and we see what comes out in the discussion
2016-09-11 22:14:14<@WilliamH> leio: we are not talking about stabilization, but keyword requests.
2016-09-11 22:14:23< Soap___> dilfridge: thats why I tried to sidestep the -ml :P
2016-09-11 22:14:24< leio> <Soap___> leio: I thought ALLARCHES was just that if one got stablised, so could the others, without any preconditions
2016-09-11 22:14:40< Soap___> but ok, lets see what the community at large says
2016-09-11 22:14:45< leio> I'm saying there is or should be a precondition of an older version already being stable.
2016-09-11 22:14:45<@dilfridge> yeah, but in general council decisions need ml discussion first :P
2016-09-11 22:15:04< prometheanfire> leio: or at least keyworded
2016-09-11 22:15:05< prometheanfire> :D
2016-09-11 22:15:14< Soap___> but yes, I see, there will be AT resistance
2016-09-11 22:15:14<@WilliamH> leio: there is for stabilizations. we aren't talking about stabilizations.
2016-09-11 22:15:53< leio> WilliamH: I was answering his directed question or comment at me about stable case of ALLARCHES, which came up because it was brought as a reasoning to the keywordreq case.
2016-09-11 22:16:40< Soap___> the idea is that, why should pure scripts fail?
2016-09-11 22:16:50< leio> import os
2016-09-11 22:16:52< Soap___> and even if they do, they would only fail in ~arch
2016-09-11 22:16:52< leio> shrug
2016-09-11 22:19:10< leio> some arches might be cool with keywording e.g pure python stuff, others not; could get separate agreements; I don't see s390 or m68k wanting people run around and mark half of dev-python/ ~arch for them
2016-09-11 22:20:03< Soap___> leio: like, I cant recall the last time I saw m68k in KEYWORDS anywhere :D
2016-09-11 22:20:06< leio> ok, bad examples, think of some that aren't vapier-only mostly after armin76 retirement
2016-09-11 22:20:15< Soap___> this would likely be more for arm/ppc maybe sparc
2016-09-11 22:20:26< leio> but your proposal covers m68k there ;)
2016-09-11 22:20:43< leio> I'm saying for keywords a per-arch agreement makes more sense, and I guess you'll hear that on ml :)
2016-09-11 22:21:18< Soap___> sure, I dont see m68k as a hindrance
2016-09-11 22:21:35< Soap___> in fact, if like half of all arches give concent, that in itself would be quite a win already
2016-09-11 22:21:40< Soap___> consent*
2016-09-11 22:21:50< leio> as for pure scripts, as in, python, not breaking stuff; that is just wrong when they aren't leaf packages
2016-09-11 22:22:16< leio> oh wait, nvm, that's for stablereq case
2016-09-11 23:51:35-!- mode/#gentoo-council [+o rich0_] by ChanServ