diff options
authorUlrich Müller <>2016-04-10 22:56:40 +0200
committerUlrich Müller <>2016-04-10 22:56:40 +0200
commit777ac348511b2a8d3743caf2cb319f123ffbc9bb (patch)
treedaa0cd08bbd063c53cbae73c5fcb89cb3c9ba4fd /meeting-logs
parentProof of concept for an index (diff)
Log for 20160410 meeting.
Diffstat (limited to 'meeting-logs')
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:
+<ulm> I suggest that we start [21:05]
+<ulm> first topic is approval of GLEP 68
+<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 [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:
+* WilliamH yes
+* blueness yes
+* ulm yes
+* dilfridge yes [21:17]
+<ulm> rich0: ?
+* rich0 yes
+<ulm> unanimous then
+<ulm> next: ChangeLog files [21:18]
+<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
+<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:
+<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:
+<WilliamH> unclear...
+<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> bug 569914 [22:07]
+<willikins> "Missing summary for 20150727
+ council meeting"; Doc Other, Project-specific documentation; CONF;
+ ulm:dilfridge
+<ulm> bug 571490
+<willikins> ulm: "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: "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: "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: "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: "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:
+<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 |
+ |
+" [22:21]