path: root/meeting-logs/20160410.txt

* 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]