* K_F is here time [21:00] roll call * rich0 here * dilfridge here * WilliamH here blueness: jlec: * jlec here hm, blueness was here 45 minutes ago [21:02] lets give it a few minutes, aenda isn't too packed yeah anyway, the agenda: https://archives.gentoo.org/gentoo-dev-announce/message/6f010dc747afcb9669711d09c690678c I suggest that we start [21:05] first topic is approval of GLEP 68 https://archives.gentoo.org/gentoo-project/message/a292e9567fac838681899b50dff24cce anybody wanting a discussion? [21:06] I read through it again and there is nothing I spotted so no from me this is just a formal approval of what we have discussed before, or are there some last minute large changes? ulm: what language format should we use finally? i recall you wanting to discuss hat right, there was some minor last-minute issue about the lang attribute [21:07] the question is if we leave it at ISO-639-1, i.e. two-letter language code I guess we could allow three-letter codes as well ulm: what are the advatages for one or the other? [21:08] *Advantages three letter codes also include Klingon there are more languages with a 3 letter code allowing both sounds like it increase complexity of parsing, what would be the benefit ? so if we choose 3 it should be only that imho [21:09] here K_F: nope, that would make things incompatible with how this is usually handled [21:10] RFC 5646 or 4656 I don't remember the number reading it now [21:11] there's also xml:lang="" that's part of xml itself maybe we should keep it at the 2 letter code for now [21:12] can be extended if there's a real need sounds like a good idea sounds good to me I don't see the real need of 3 letters now. I would assume ISO-639-1 covers the most used. xml mentions http://www.ietf.org/rfc/bcp/bcp47.txt [21:13] mgorny: things get complicated very fast enochian... :| [21:14] not sure if we want tags like sl-IT-rozaj-biske-1994 for now [21:15] ulm: :) I favor a KISS approach, extending it if necessary that was an example from bcp47 are we ready to vote on the GLEP then? [21:16] nothing more from me at least I would say yes so consensus is keep it at 2 characters yes i’m okay with the GLEP and ready to vote yes yes to 2 chars i mean so, vote for approval of GLEP 68 yes * K_F yes current text: https://wiki.gentoo.org/index.php?title=GLEP:68&oldid=486306 * WilliamH yes * blueness yes * ulm yes * dilfridge yes [21:17] rich0: ? * rich0 yes unanimous then next: ChangeLog files [21:18] https://archives.gentoo.org/gentoo-project/message/402eb403e0f451e7bc0525b76e9d3da2 We said we don't require them to be generated, so imo if infra wants to stop, it's up to them. first question is if we continue to provide ChangeLogs at all [21:19] or even, if we leave the decision to infra ulm: Didn't we already answer that? I don’t think we need change logs WilliamH: not sure ulm: I mean we voted that we don't require them to be generated. But that was before the switch and now people are requesting them and I would like to see it supported for them [21:20] As far as I'm concerned infra can do whatever it prefers here. My personal opinion is also that they should be killed. It makes sense to have ChangeLogs next to the files But Have a CHANGELOG_RSYNC variable in make.conf to easily switch of ChangeLog per rsync [21:21] It isn't even clear that infra is formally requesting a decision from us. But, I'm fine with them going, or staying. Provide strip down Changelog with one year or 10 entries history to strip down size. Everything else is online available jlec: that sounds like a good idea jlec: everything is already online if people really want it That way, we strip down size and make the pull via rsync optional so you want to make changelogs just practically useless? :( jlec: one year, or 10 entries, whatever is larger? [21:22] We have already said that they are optional. WilliamH: But not everybody can always easily access that and it is some much more convinient to have the ChangeLog near the actual files That was decided last year. WilliamH: online has *HORRIBLE* usability ulm: correct (who thinks of the users?) strip down doesnt really make much snese xiaomiao: enough xiaomiao: who’s asking for the ChangeLogs, the users or developers? xiaomiao: ultimately it is up to whoever is willing to do the work to maintain them. [21:23] blueness: both blueness: both blueness: I want changelogs so I can figure out why something doesn't work I have no problem with changelogs being there, or not. I'm more in favor of a variable to ignore it during rsync (and by extension by the package manager during OpenPGP signature validation process) for developers i think just use git for users its a thornier question blueness: that means checking on a different machine, at a different point in time with a growth rate of 43 MiB per year my feeling is that we have to act on it sooner or later I don't get why we're even making a decision here. Has somebody actually asked for permission to remove them? very bad for figuring out breakage but iirc we have left it up to infra if they want to continue generating it at all and apparently it slows down the overall stating process and causes issues K_F: has infra actually said that? [21:24] I've seen an infra member say that. But, is that the project's decision? Are they actually seeking to remove them? The project has already opened the way for removing them. And if so, do they just want us to re-iterate what we said prevsiously? rich0: I haven't seen a formal decission just based on lurking and comments here and there about the SIZE of the changelogs: we could probably exclude robbat2's initial commit with its looong message rich0: robbat2 indicated it rich0: I think they are complaining about all the hassle with generating them There is a link somewhere wrt a formal decision we made last year about not requiring changlog generation once we were in git [21:25] My suggestion is to defer to them. If they feel generating changelogs isn't worth it, and others feel that it is, then let the others generate them. give me a few I'll find it [21:26] We're a volunteer distro. Ultimately things get done when people care enough to do it themselves. rich0: the master mirror is hosted by infra, so there's no good way to have them generated by others ok, so what is the problem we're trying to solve? 1) hassle of generating and pointing users at inofficial resources is kinda ... not good 2) size of the portage tree :P ulm: you don't need mirrors to GENERATE changelogs. You /might/ need them to distribute them. dilfridge: s/portage/Gentoo/ but :) [21:27] xiaomiao: why not? that's what the :P was for dilfridge: and following that, excess bandwidth usage during sync and what makes it unofficial? rich0: let's assume I host it, and then break stuff Any dev can officially host them. do you want to be the one that cleans up the PR disaster? rich0: that'd break signature validation of manifests rich0: if doing it as part of full tree anyhow IF we want to solve 1), we can only drop the changelogs K_F: they could sign with their own keys if they wanted [21:28] IF we want to solve 2), we can consider making the download somehow optional rich0: right dilfridge: or truncate them xiaomiao: what do we do when infra breaks things? It isn't like infra has some magical quality. rich0: sometimes we supply patches and wait a week or three How about having a tool which pulls the ChangeLog from the internet on request jlec: nooooo reason? that's exactly what the users that want changelogs won't tolerate because not everyone has a reliable fast internet connection [21:29] jlec: likely the users needing changelogs doesn't have too active internet xiaomiao: then just host an rsync server and provide them the way they've always been provided. That's how just about anything gets done these days. but personally I don't think the overhead is worth it. that said, I think it should be left up to infra mostly unless we get complaints about a slow sync process [21:30] So what is the reason against ChangeLogs in rsync? Only the infra complain? jlec: storage requrement, bandwidth requirement of users jlec: if the only reason was that infra didn't feel like building them, that would be reason enough to get rid of them and at the same time, if unnecessary bandwidth usage by mirrors and changelogs are used rarely If somebody feels like doing it, let them join infra or start their own infra (also allowed under GLEP 39) So we need RSYNC_CHANGELOG or such [21:31] rich0: hahahaha. oh you. problem one solved jlec: well, that only goes if infra still generates it right xiaomiao: being rude isn't helpful rich0: you should know better xiaomiao: I'm completely serious but really, someone who likes ot have it, should implement a working and performant solution [21:32] What is stopping you from forming your own infra? rich0: then you're just being willfully ignorant xiaomiao: of what? can we please stay on topic rich0: among other things, lack of access to the DNS records of gentoo.org xiaomiao: Just ask for a subdomain I'm sure they'd be happy to help you out ++ rich0: >_< we both know how that works xiaomiao: I've never asked them for a subdomain. Have you? [21:33] rich0, dilfridge: ++ ... in any case.. I'd really like to hear a formal infra response before making any decision on ChangeLogs rich0: I have had enough discussions with the relevant people to know it's an absolute no-go we already put in place the framework for that long ago, and nobody was ever interested, including xiaomiao I'm not entirely sure one is needed to begin with, so can just defer it to infra at all dilfridge: eh? xiaomiao: well, then put it on the council agenda if it bothers you unless we feel users are being burdened by current status quo rich0: I like your optimism, but don't see how that helps [21:34] and if they want to remove changelogs I'm fine with it can we stay on topic please? topic is if changelogs should be generated not if we should have a second infra [21:35] We're getting off-topic. I'll certainly agree that infra manpower is sometimes limiting, and we need a better way to let other devs contribute to infra-like projs. I'm all for helping to make it happen, and I suspect that if somebody has a sane plan that most would support it. rich0: iirc it isn't about manpower, but the slowness of extraction of changelog from git rich0: so if it is too slow, and it blocks manifest generation etc, in particular if mirrors get a partial sync things breaks [21:36] In any case, I can't see a reason to tell infra that they're not allowed to do what they think is best here. K_F: that was my impression too, that it was a technical issue and if adding protection for that to ensure it is atomic, it might slow down rsync * WilliamH agrees with rich0 as in the full tree not being distributed for a prolonged period of time Perhaps others will solve that problem, and perhaps infra will host it, or perhaps we'll find some other way to host it. I wonder however why it would be so slow If infra feels that it is best to drop ChangeLogs I won't stop them. [21:37] information can be extracted from git in a fraction of a second, including all paths *** caveman (~Mahmoud@unaffiliated/mahmoud) has joined channel #gentoo-council i wonder if we can generate short ChangeLogs easily question for infra something that is light weight ulm: don't take the number too precisely, but I seem to recall a few (2-3 seconds) being mentioned at a time I also _think_ part of the problem is the reverse order of ChangeLogs... again that's just speculation... [21:38] ulm: and not parallellized is anyone from infra around? blueness: git log > CHANGELOG.txt K_F: also 2 or 3 seconds shouldn't pose any problem Is the script for generation publically available? WilliamH: well, that breaks rsync append only sync at least, but iirc portage at least is configured where that disabled to begin with to speed things up So, I built the git validator to go find all the changes in a git history, and it is fairly intensive. I'm sure it could be improved, but comparing 2M+ trees to find differences even in parallel can take time [21:39] * WilliamH really thinks this is an infra issue; there isn't much we can do about it or whoever decides to host the changelogs If changelogs had a limit on the number of TREE commits that were descended that would help do we know what infra wants? We don't iirc Having a limit on file commits doesn't help so much, because git doesn't have per-file histories that can be directly accessed [21:40] The way you generate a per-file history is to walk the tree history and descend to that file and look for every time it changes. I feel that dropping ChangeLogs is a strong change to how we provide the repository to the user. There need to be strong reasons for it So, finding 10 file commits might require digging through a million tree commits. And not only, that infra doesn't like to do it. rich0: you can have the log include all paths that's very fast [21:41] If there reason are just bad tools, we need to work on that ulm: sure, if you don't go through every commit. Right now it probably isn't too bad since we only have 9 months of history. Doing it with the migrated tree was still quite slow. We don't need to regenerate the full set of ChangeLogs each time [21:42] rich0: you only need the commits since the previous run A valid strategy would be to just limit all changelogs to an absolute number of tree commits or a span of time ulm: agree, if you save state and add to the files then you only need to process new commits so it's just the number of commits between each rsync release I was referring to generating them from scratch each time so now we're drifting into technical details about something that none of us has seen wiw, I believe these are the scripts: https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/ fwiw* In any case, if somebody wants to solve the technical challenge and contribute patches to infra, they can do so. At this time I don't see a reason not to give infra full discretion here. [21:43] Again, this is really over our heads, I think we should leave it up to infra. dilfridge: well, sometimes we get to pretend that we're a technical body. :) so, are we going to make any statement on this today? better that We can just re-iterate the previous decision if we wanted to. I would like to see a good reasoning on the why Or further clarify that infra has the discretion to remove or keep as they're able. [21:44] * WilliamH is composing ... rich0: "git log --name-status" takes a few seconds only, for the full git history [21:46] and it has all information that's needed i need to go downstairs for about 5 mins brb ulm: it seems egencache is used. So the question is how that tool does it [21:47] The council does not require that ChangeLogs be generated or distributed through the rsync system. It is at the discression of our infrastructure team whether or not this service continues. If it does not continue, there is nothing stopping someone else from generating or distributing these change logs. WilliamH: I don't think that we need the last sentence [21:48] ulm: ok... The council does not require that ChangeLogs be generated or distributed through the rsync system. It is at the discression of our infrastructure team whether or not this service continues. ulm: agree - it is probably doable if the software is written efficiently [21:49] any comments, or can this be put up for a vote? i.e. WilliamH's wording I'm fine with it wfm I still see a drastic change to the way we provide our repo to the user and I don't think ti should be left to infra please vote: "The council does not require that ChangeLogs be generated or distributed through the rsync system. It is at the discression of our infrastructure team whether or not this service continues." [21:50] jlec: that would be covered by the vote though K_F++ correct s/discression/discetion/ probably? *discretion correct yeah, spelling error should be fixed :) [21:51] "The council does not require that ChangeLogs be generated or distributed through the rsync system. It is at the discretion of our infrastructure team whether or not this service continues." * K_F yes please vote ^^ * WilliamH yes * jlec no * dilfridge thinks this is something the council should decide, but is ok with dropping it -> abstain * rich0 yes * ulm abstain back 1 sec blueness: ? * blueness yes [21:52] 4 yes 1 no 2 abstain dilfridge: ? motion passes abstain dilfridge has abstained If we continue providing Changelogs, then what should be their order of entries? ok so what is the count then? WilliamH: see above, 4 yes 1 no 2 abstain [21:53] 4 yes 1 no 2 abstain ulm: reverse should we recommend order of the logs, or leave that to infra too? if we leave whether to have logs or not to infra, we should leave order to them as well imho [21:54] * WilliamH agrees w/ K_F the logs should be most recent change first looks like almost everybody prefers newest first, though That's a part of the problem K_F++ - they can take a poll if they want to know what people prefer, I don't think they need us to tell them newest first means the whole file has to be transferred via rsync every time rich0: iirc they have already done so :) how about: "the council strongly recommends that ChangeLog files are in the order of newest entries first" WilliamH: afaik current rsync settings transfer the whole file anyway [21:55] ulm: not sure how strongly I feel about it .. they have done a poll, and an overwhelming majority was for newest-first oreder *order If they feel that rsync transfer issues matter more, then that can be their call Wasn't the overwhealming majority for killing the changelogs? WilliamH: nope Show me the poll again? [21:56] WilliamH: that's not entirely clear from that poll I'd say a majority wanted them, or simply didn't care Actually, only a minority really wanted them to stay or go. The poll questions were part of the problem... WilliamH: https://archives.gentoo.org/gentoo-project/message/c2ffa62837fd4cbdd42945bf57b09b25 unclear... http://dev.gentoo.org/~robbat2/201602-portage-survey/ In any case, infra knows what will make people happy. If they don't think they can do it, then somebody needs to help them out. [21:57] I can't recommend which way is better without understaning the resource/etc constraints could we please at least decide *something* today? :) We did just approve a GLEP - that only happens about once a year any more. ulm: robbat2 even said in that msg that ~60 [21:58] dilfridge: "If ChangeLog files are provided, thay should be in the order of newest entries first"? ulm: ~60% are for getting rid of them. *they yep ulm: I prefer a wording that says recommend barring technical limitations I'm fine with that- we can read the polls as well, but we don't have the info needed to fully decide for them. [21:59] K_F: that would be too vague recommend unless there are strong technical reasons? WilliamH: I would consider 40% to be enough to keep them jlec: not me, majority rules... [22:00] WilliamH: majority rule in a somewhat informal survey isn't necessarily sufficient, imho jlec: when we vote here, if something passes by one vote it passes. WilliamH: perhaps 60% devs who use git and 40% users who use rsync tyranny of the majority isn't always correct (alexis de toqueville etc) WilliamH: what then? K_F: we just decided that infra can drop them altogether, so what technical reasons would remain [22:01] we could say "strongly recommend" instead of "should" We already gave infra the decision about ChangeLogs andyway, so let's leave the order to them too ulm: the only rationale I can see is if they can keep them if they can save sufficient bandwidth from reverse order i.e reverse reverse.. [22:02] K_F: we just voted that what happens is at infra's discretion. K_F: so what they do they do. I'm completely fine with not saying anything about order ++ let's just vote: "If ChangeLog files are provided, they must be in the order of newest entries first" [22:03] * K_F abstain * ulm yes [22:04] * dilfridge yes * rich0 no * blueness yes * jlec yes * WilliamH abstains [22:05] I count 4 yes 1 no 2 abtentions actua actually motion passes change my vote to no 4 yes 2 no 1 abstention then motion still passes more comments on the topic of changelogs? [22:06] next: open bugs 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=3129620&query_format=advanced bug 569914 [22:07] https://bugs.gentoo.org/569914 "Missing summary for 20150727 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:dilfridge bug 571490 ulm: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Doc Other, Project-specific documentation; CONF; mgorny:council logs are all up now dilfridge: any progress? as are lists of attendees rest coming bug 566498 [22:08] ulm: https://bugs.gentoo.org/566498 "games.eclass: use of games group needs to be removed wrt 20151011 Council meeting"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games bug 574080 ulm: https://bugs.gentoo.org/574080 "games.eclass: Path customization needs to be removed wrt 20151213 Council meeting"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games bug 574952 ulm: https://bugs.gentoo.org/574952 "Games team intentionally ignoring messages and bugs in order to stall QA and Council"; Community Relations, Developer Relations; CONF; mgorny:comrel ulm: i have yet to add the summary from last month, i’ve just been too busy, but i’ll get to it [22:09] IMO with the games I suggest somebody just step in and do it. I don't see what the council is supposed to do there Pestering the games team to do something they don't want to do isn't helpful I suggest removing us from CC If they start reverting commits by all means take it to devrel/QA/etc err, comrel for all three bugs sounds good However, we can't chain them to their keyboards and make them implement something. sounds good to me one of us could just do it [22:10] the policy decision is made already, its just implementation left somebody needs to do it As with all things FOSS, it ultimately comes down to somebody willing to do the work. dilfridge: you're volunteering? is it a matter of just gutting the class? or does it need a rewrite, i haven’t really looked? how much work are we talking? or blueness? not really, I need to finish version-bumping and stabilizing dev-perl first... [22:11] i’m not sure i’m volunteering, i just wonder how much work it is well and i’m busy with libressl right nwo as is dilfridge :) just changing the eclass in place is possible, just probably not fully qa-consistent (doesnt affect installed packages, just reinstallations) [22:12] dilfridge: the problem is if we just gutt the class we’ll break a bunch of ebuilds gutting = stubbing functions so, leave council in CC? I fear there won't be much progress unless we assign the action to someone leave it in cc for now [22:13] k last is bug 579460 ulm: https://bugs.gentoo.org/579460 "please make repoman ignore a missing "# $Id$" header line"; Portage Development, Repoman; CONF; dilfridge:dev-portage yeah, we can always defer it and keep in cc ulm: I don't see an action, there is a previous council decision and bug is too new [22:14] that's not really an action item for us do we need to reiterate the general question no we dont i.e. that $Id$ can be dropped we have an unanimous decision there already I only cc'ed council for informational purposes Oh do we have a decision about $ID$? [22:15] WilliamH: https://projects.gentoo.org/council/meeting-logs/20141014-summary.txt "Can we drop CVS headers post-migration?" was accepted unanimously WilliamH: you had voted yes :) [22:16] Hmm, now if only we could get paid to keep re-deciding the things we've already decided on... :) ulm: In that case, let's do it. WilliamH: the way I see it, the bug is the "lets do it" part [22:17] after repoman is fixed, yes ++ anyway, let's move on open floor nothing? [22:18] * ulm bangs the gavel [22:19] done! yeeeeah thanks everybody Thanks for the cat herding! :) *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: 2016-05-08 19:00 UTC | http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160508T19 | https://wiki.gentoo.org/wiki/Project:Council" [22:21]