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