path: root/meeting-logs/20170514.txt

[21:09:41] <blueness> --- start ---
[21:09:43] <blueness> ping blueness dilfridge jlec K_F rich0 ulm williamh
[21:09:44] <blueness> ping  dilfridge jlec K_F rich0 ulm williamh
[21:09:56] <dilfridge> here
[21:09:58] -*- K_F here
[21:09:58] -*- WilliamH is here
[21:10:04] -*- jlec here
[21:10:06] -*- rich0 here
[21:10:09] -*- ulm here
[21:10:14] -*- dilfridge here
[21:10:32] <blueness> okay agenda at http://dpaste.com/2Y2NZ7N
[21:11:03] <blueness> 1. Roll call - looks like everyone is present
[21:11:20] <blueness> if the agenda looks okay, let's move on to item 2
[21:11:42] <blueness> 2. Discussion on Guidelines for the council summaries - https://archives.gentoo.org/gentoo-project/message/7d6a15b12347ce173609e0f50595fbc0
[21:11:56] <dilfridge> ok so
[21:12:03] <blueness> dilfridge: that's yours so do you want to start commenting?
[21:12:09] <dilfridge> as said in the e-mail, this is not something we need to vote on
[21:12:17] <dilfridge> it's just a list of suggestions
[21:12:27] <dilfridge> about the reasons
[21:12:39] <blueness> dilfridge: i'm okay with all your suggestions but what's the problem?
[21:12:44] <dilfridge> no problem at all
[21:13:01] <rich0> The only suggestion I'd make is that rather than posting agendas/summaries in emails, it might make more sense to link them.
[21:13:04] <K_F> blueness: reading through the older summaries leaves something wanting, having guidelines on it seems like a good idea
[21:13:04] <dilfridge> I'm reading old summaries, and that turns up all sorts of problems in those
[21:13:07] <rich0> To the wiki...
[21:13:20] <K_F> ini particular broken links etc in the historical ones making it difficult to get context
[21:13:24] <rich0> Certainly for summaries/etc.  Agendas are probably more open to debate, since I don't think we log those on the wiki.
[21:13:26] <jlec> dilfridge: I like it.
[21:13:33] <dilfridge> in particular, broken links are a problem, 
[21:13:37] <rich0> But, in general I'm fine with it.
[21:13:39] <ulm> maybe s/A link to the meeting agenda/The meeting agenda or a link to it/ in item 2?
[21:13:50] <dilfridge> and stuff gets forgotten if it was decided between meetings and isnt mentioned in the log / summary
[21:13:59] <rich0> Links should be to places that are fairly durable though.
[21:13:59] <ulm> otherwise all that is fine
[21:14:00] <blueness> rich0: i've always put the agenda at the top of my summaries
[21:14:06] <dilfridge> works for me
[21:14:09] <rich0> Links to agendas in your dev web space not so good...
[21:14:12] <K_F> ulm: in most cases the agenda should be covered by the summary itself as it should follow it to begin with
[21:14:19] <blueness> links to mail archives are okay
[21:14:22] <rich0> I personally use the agenda to create the summary.
[21:14:33] <WilliamH> rich0: ++
[21:14:38] <dilfridge> so if that's ok for you I'll just update the council page with a slightly amended version of the mail
[21:14:55] <ulm> also 3 is due to a technical limitation
[21:14:56] <dilfridge> or a subpage, weherever
[21:14:59] <WilliamH> for me personally it is easier to use the agenda to create the summary
[21:15:09] <WilliamH> list each item and what happens with it.
[21:15:09] <ulm> once that's fixed we won't need 3 any more
[21:15:16] <dilfridge> ulm: yes, but...
[21:15:37] <ulm> I agree that for the time being attachments should be avoided
[21:15:39] <dilfridge> anyway, you've all seen it, I dont think we need a long discussion
[21:15:51] <rich0> Yup, I'm fine with it in general.
[21:16:09] <blueness> dilfridge: yeah sounds good to me
[21:16:21] <K_F> the principle of better summaries, and ensuring it is reachable also for posterium is good, the listed guidelines are good help for that
[21:16:34] <K_F> but I agree we likely don't need a vote on the specific guidelines
[21:16:47] <K_F> maybe we should write a wiki page or something on it and keep up to date, though?
[21:17:03] <K_F> maybe under Chairing role or something
[21:17:24] <blueness> i think we're in agreement, dilfridge add the stuff to the wiki and let's move on
[21:17:28] <dilfridge> ++
[21:17:31] <K_F> responsibilities of the meeting chair
[21:17:58] <blueness> K_F: let's not slide into defining full roles for chair though
[21:18:04] <blueness> okay moving on
[21:18:15] <blueness> Discussion on arches.desc & GLEP 72
[21:18:25] <blueness> https://archives.gentoo.org/gentoo-project/message/a0babd1fcfd6471bfa9afd76e51a4c3b
[21:18:33] <blueness> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
[21:18:46] <blueness> dilfridge: that's you again, do you want to introduce us to this glep
[21:18:52] <dilfridge> ok 
[21:19:04] <dilfridge> so, at the moment we have three problems
[21:19:39] <dilfridge> the first one, the most trivial one, is that there is no clean "algorithmic" way to find out if an arch is "stable", whatever that means
[21:20:09] <dilfridge> tools like eshowkw solve that by checking if an arch has stable profiles in profiles.desc, but that's not a good solution
[21:20:28] <dilfridge> second, we have arches like m68k
[21:20:55] <dilfridge> where stable keywords *exist* in the tree, but the arch is not stable (per council decision)
[21:21:31] <dilfridge> this means that all profiles must be set to exp, and effectively repoman checking is turned off
[21:21:49] <dilfridge> even though repoman checking would make sense for ~m68k 
[21:21:58] <dilfridge> (keeping a consistent unstable deptree)
[21:22:18] <dilfridge> third, it's hard to prepare an arch for stabilization, 
[21:22:48] <dilfridge> basically the arch team has to make a fully consistent deptree and then switch a profile to stable at one point in time
[21:22:56] <dilfridge> which is not easy
[21:23:17] <dilfridge> the intention of the GLEP is to address these three things
[21:23:45] <dilfridge> it introduces one new file, called profiles/arches.desc, in analogy to profiles/profiles.desc
[21:24:12] <dilfridge> lines with space-separated columns
[21:24:23] <blueness> dilfridge: one clarification: repoman can be made to include dev and exp arches making addition of a full stable dep tree possible, eg for mips
[21:24:46] <WilliamH> So, a question from me too.
[21:24:57] <dilfridge> blueness: true, but the next developer will have that switched off and inadvertently break the deptree again
[21:25:17] <Soap__> dilfridge: will that require devs to KEYWORDREQ m68k then?
[21:25:19] <K_F> dilfridge: can't that be made into a question of defaulting repoman to -d ?
[21:25:21] <WilliamH> If w e introduce arches.desc, why would we still need profiles.desc?
[21:25:55] <dilfridge> ok one after the other
[21:26:09] <blueness> dilfridge: i'm confused as to how repoman would use arches.desc
[21:27:03] <dilfridge> WilliamH: Yes, we still need profiles.desc. First, it provides the list selectable with eselect. Second, it describes which profiles of an arch are tested by repoman. Third, 
[21:27:35] <dilfridge> it provides the classification of dev / exp, and thereby the possibility to "turn off" checking.
[21:28:32] <dilfridge> Soap__: KEYWORDREQ for m68k, yes if repoman complains on broken deptree (and technically you should file them now, too)
[21:28:34] <ulm> also we cannot remove profiles.desc without an EAPI bump
[21:28:51] <ulm> even if we wanted
[21:29:07] <dilfridge> K_F: defaulting repoman to -d solves a different problem
[21:29:22] <dilfridge> blueness: give me another 2-3 lines to describe it
[21:29:24] <Soap__> dilfridge: i.e. more ppc/ia64/sparc?
[21:29:54] <dilfridge> Soap__: just introducing the file doesnt change anything, the default settings mirror what we have now
[21:30:03] <blueness> dilfridge: k
[21:30:29] <dilfridge> so it introduces three states per architecture
[21:31:03] <WilliamH> dilfridge: can't you answer 2 an 3 above though by some combinations of the second and third columns of  arches.desc?
[21:31:03] <dilfridge> "stable" is the default and the behaviour we have now... amd64 and ~amd64 describe two different deptrees, which both have to be consistent
[21:31:53] <dilfridge> "mixed" means repoman treats m68k internally as ~m68k, and checks consistency only for ~m68k
[21:32:18] <dilfridge> "unstable" means mips is invalid and generates an error, and consistency is checked for ~mips
[21:34:03] <blueness> .... thinking ....
[21:34:26] <blueness> dilfridge: suppose i wanted to transition mips to be like m68k, how would i do so??
[21:34:27] <dilfridge> WilliamH: I dont see how arches.desc could provide a list of *profiles*. One could replace the "stable"/"dev"/"exp" classification of profiles maybe with an arch-based mechanism, but then we lose flexibility again.
[21:34:29] <dwfreed> btw, repoman -d is only dev profiles, you need -ey for exp profiles too (annoyingly -e takes an option, -d does not)
[21:34:52] <ulm> dilfridge: we don't want a column specifying if the arch is security supported?
[21:35:01] <dilfridge> ulm: we can add that too
[21:35:15] <dilfridge> blueness: you add a line stating "mips mixed"
[21:36:09] <blueness> dilfridge: would you hit inconsistencies?
[21:36:16] <dilfridge> blueness: in what sense?
[21:36:46] <blueness> dilfridge: suppose you add only some mips keywords, and some deps are only ~mips, would that show up?
[21:37:14] <dilfridge> in that "mixed" setting, by default repoman would accept that just fine
[21:37:17] <blueness> ie you add some stable mips keywords to an ebuild, but that ebuild has some ~mips only dependencies, would that throw an error?
[21:37:32] <dwfreed> no
[21:37:37] <dol-sen> blueness no
[21:37:43] <blueness> got it
[21:37:52] <dilfridge> however repoman could have an additional switch which - for that one repoman run - upgrades mips from "mixed" to "stable", and then it shows an error
[21:38:09] <dol-sen> it would allow you to work on making enough ebuilds with stable arch keywords to allow a change to stable
[21:38:11] <dilfridge> which is useful for the arch team to prepare the stable deptree
[21:38:37] <dwfreed> "mixed" has the expectation that the user has (either by profile or by make.conf) ACCEPT_KEYWORDS="~${ARCH}"
[21:38:48] <dilfridge> yes
[21:39:34] <dwfreed> (also same would necessarily apply for "unstable")
[21:39:44] <dilfridge> obviously, yes
[21:41:45] <blueness> dilfridge: i feel a bit uneasy abou tthis because it seems like there are two many disperate ways of saying what keywords are accepted, but i don't have a better solution right now
[21:43:00] <dwfreed> stable/dev/exp on profiles has no bearing on depgraph consistency itself; it only controls what flags enable repoman checking of that consistency
[21:44:00] <blueness> i'm wondering if we need to do anything with catalyst
[21:44:09] <leio> as soon as people stopped just always passing -d, this became useless
[21:44:15] <blueness> because it also respects profiles.desc
[21:44:43] <leio> mixed is meant to allow using catalyst with a stable tree, i.e you only stabilize what you are going to want for stage building, without caring about non-default USE flag deptree
[21:44:45] <dilfridge> blueness: I can't imagine that this affects catalyst, because it doesnt affect emerge
[21:44:56] <dilfridge> only repoman and similar qa tools
[21:45:42] -*- WilliamH agrees with dilfridge 
[21:45:50] <leio> (I don't know about stage building to know why such a stable marking is necessary really)
[21:45:50] <WilliamH> I don't see how this would affect catalyst
[21:46:03] <dol-sen> it wouldn't no
[21:46:10] <blueness> dilfridge: k
[21:46:10] <blueness> WilliamH: catalyst reads profiles.desc
[21:46:29] <WilliamH> blueness: Why?
[21:46:34] <Soap__> also, we're back at the ppc/ia64/sparc mess
[21:46:39] <blueness> 1 sec
[21:47:01] <blueness> WilliamH: oh wait, its not for exp/dev/stable, but for legitimate profiles
[21:47:37] <Soap__> blueness: so the stable keywords argument is moot?
[21:47:45] <WilliamH> blueness: ok, so we are good then.
[21:48:40] <blueness> WilliamH: yeah, to be clear, catalyst throws an error if /etc/portage/make.profile doesn't point to a directory listed in profiles.desc
[21:49:08] <blueness> Soap__: i think if we drop ppc to mixed, we relieve the problem we've been discussing on the list
[21:49:32] <rich0> leio: I don't have firsthand knowledge but I think the principle is that they'd do a stable stage3 build (ACCEPT_KEYWORDS=arch, not ~arch).  Presumably they do this because the ~arch packages might be broken.
[21:49:36] <WilliamH> blueness: hrm, that might be an error in itself, but that's another topic for another time.
[21:49:40] <ulm> dilfridge: what about stabilisation tools that allow an "all" keyword? would they act on all stable, or on stable+mixed?
[21:49:56] <dilfridge> heh
[21:50:00] <dilfridge> good question
[21:50:10] <rich0> Honestly, I think they'd do better to just try to go for straight stable in this case, but maybe they want more flexibility around the keywording.
[21:50:25] <dilfridge> I'd suggest: by default, act on "stable"; with switch, act on "stable+mixed"
[21:50:44] <WilliamH> dilfridge: sounds reasonable.
[21:51:06] <dilfridge> same idea as with repoman, a switch for "arch team work"
[21:51:06] <ulm> e.g. ekeyword allows all, and so does ebuild-mode
[21:53:10] <rich0> Ok, I unfortunately have to take off.  Sorry I get to miss the moderation discussion.  IMO this seems like something we should seriously consider polling the devs about, since it is impactful and controversial, but personally I'm all for reviving the proctors in some form...
[21:53:20] <leio> ALLARCHES should be just "only stabilize if older version has stable keywords" and it doesn't matter if stable or stable+mixed
[21:54:05] <WilliamH> leio: that's a good idea too.
[21:54:18] <WilliamH> leio: base it on the status of older versions of the package.
[21:54:25] <ulm> but complicated, because the tool has to look into other ebuilds then
[21:54:48] <leio> but that's how keywording works, across versions
[21:55:01] <ulm> true
[21:55:13] <K_F> ulm: at the time of stabilization, eshowkw etc will do that anyways
[21:56:08] <blueness> dilfridge: i'm still having difficulty following the workflow here ... suppose we drop ppc to mixed ... then repoman won't complain about stable ebuilds depending on unstable ebuilds, but emerge will, so how are users to deal with that?
[21:56:18] <K_F> I generally agree with the basis of this GLEP, but I don't believe we're ready for a vote in this meeting. I agree with ulm that we likely want security supported as a column, and there are some minor details to iron out
[21:56:39] <dilfridge> blueness: "mixed" assumes that users only run ~arch
[21:56:42] <ulm> K_F: +1
[21:56:54] <dilfridge> and that whatever stable keywords exist are "internal" for the arch team
[21:57:02] <dilfridge> K_F: works for me
[21:57:22] <leio> but please get this sorted with implementations by next meeting, as I shall be back with some time to poke at arm64 and mips ;)
[21:57:24] <blueness> dilfridge: so suppose i'm building stage3's with stable arch keyword, i have to make sure there is consistency between the stable keywords for @system, correct?
[21:57:36] <ulm> dilfridge: "premium_unstable"? :)
[21:57:48] <K_F> to have it in the public channel as well, the minor details includes typo fixes and changing comment section (#) to be in line with PMS to not require different parsers
[21:57:49] <dilfridge> blueness: essentially yes, for your own fun and profit
[21:57:55] <dilfridge> ulm: with extra legroom, yes
[21:58:09] <blueness> dilfridge: that is the way vapier is treaking m68k
[21:58:32] <dilfridge> right, and that's what it is modelled after
[21:59:01] <WilliamH> So what do we want to do with ia64 and sparc?
[21:59:18] <dilfridge> different topic
[21:59:28] <blueness> okay guys, we're not ready for any vote now, and we should move on
[21:59:31] <dilfridge> so how about, the discussion of GLEP 72 is tabled for next time
[21:59:43] <blueness> dilfridge: yes, let's table it
[21:59:57] <K_F> dilfridge: thanks for working on it
[22:00:10] <dilfridge> np
[22:00:11] <blueness> ditto, thanks dilfridge
[22:00:37] <blueness> next4. Open bugs with council involvement [4]
[22:00:48] <blueness> Bugs 618254, 616206, 565566
[22:00:54] <blueness> let's to through each
[22:01:04] <blueness> bug #618254
[22:01:17] <blueness> hmmm no wilikins
[22:01:18] <dilfridge> bug 618254
[22:01:25] <ulm> secret bug
[22:01:27] <K_F> blueness: its restricted by group
[22:01:31] <blueness> ah yes!
[22:01:37] <K_F> its likely not an issue for the public channel
[22:01:59] <jlec> I think it is ComRel business
[22:02:04] <K_F> arguably that isn't a council...
[22:02:06] <K_F> exactly
[22:02:16] <Soap__> no
[22:02:20] <blueness> K_F: i agree, we don't need to discuss that now
[22:02:27] <Soap__> it was explicitly requested that the council votes on it
[22:02:45] <ulm> Soap__: not now and not in public
[22:03:23] <blueness> okay how about we deal with that one by posting on the bug before next meeting
[22:03:34] <blueness> so let's move on
[22:04:02] <blueness> Bug 616206 - EAPI 6 reapproval
[22:04:04] <willikins> blueness: https://bugs.gentoo.org/616206 "EAPI 6 reapproval"; Gentoo Hosted Projects, PMS/EAPI; IN_P; ulm:council
[22:04:16] <K_F> that has already been voted on, so it is just to record results in summary
[22:04:18] <jlec> Approved
[22:04:24] <dilfridge> that's already done and is hereby referenced
[22:04:25] <blueness> yeah i think we can close that no?
[22:04:27] <dilfridge> ++
[22:04:30] <ulm> yep, that can be closed
[22:04:50] <ulm> the PMS version is released and also online
[22:05:06] <K_F> but goes back to initial summary discussion for proper recording, I like the idea of keeping open until next meeting etc
[22:05:33] <K_F> and also the form of voting in-between meetings, not waiting for next
[22:06:11] <blueness> i just closed it
[22:06:12] <blueness> Bug 565566 - New ChangeLogs are in chronological order
[22:06:12] <blueness> i'm not sure what we need to do for that one
[22:06:14] <willikins> blueness: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
[22:06:32] <K_F> blueness: I don't believe there is anything new for us on that one
[22:06:38] <WilliamH> blueness: we are still waiting for infra
[22:06:41] <blueness> yeah
[22:06:44] <NeddySeagoon> Announce the results of votes between meeings at the next meetin, so that there is a record in the log
[22:06:46] <ulm> I'm not aware of any progress
[22:07:06] <K_F> NeddySeagoon: yes, thats why it is kep open until now and mentioned
[22:07:14] <ulm> I count 7 yes votes. So this has been approved unanimously by the council.
[22:07:17] <K_F> NeddySeagoon: it'll be in summary
[22:07:17] <blueness> NeddySeagoon: okay regarding Bug 616206 - EAPI 6 reapproval -> unanimously passed
[22:07:17] <willikins> blueness: https://bugs.gentoo.org/616206 "EAPI 6 reapproval"; Gentoo Hosted Projects, PMS/EAPI; IN_P; ulm:council
[22:07:50] <blueness> okay guys, let's move on to 5. Mailing list moderation
[22:08:01] <blueness> https://archives.gentoo.org/gentoo-project/message/ad3bbffe2286cced97b64571edc1245d
[22:08:25] <blueness> my 2 cents, no need for moderation of the lists
[22:08:37] <K_F> blueness: I tend to agree
[22:08:40] <ulm> we had discussed that in december already
[22:08:51] <blueness> yep, this keeps resurging
[22:08:54] <dwfreed> I think we need to do something
[22:09:05] <blueness> dwfreed: why and like what?
[22:09:18] <dwfreed> as to why, that can be answered with one word: wltjr
[22:09:40] <blueness> dwfreed: there may be other solutions
[22:09:44] <jlec> I don't see moderations necessary. With my limited time currently I can still catch up with what is really important. It's easily spottable what is productive.
[22:09:59] <K_F> I don't see an overall level of emails that results in a need for moderation of the lists
[22:10:12] <dwfreed> I'm not saying every post needs to be moderated
[22:10:19] <dilfridge> wltjr is slowly dominating the public perception of gentoo
[22:10:24] <dwfreed> or even every post from not-devs
[22:10:29] <ulm> basically it's one single person causing trouble there
[22:10:29] <dwfreed> but that ^^^ is very important
[22:10:37] <ulm> not a case for general moderation
[22:10:37] <jlec> I personally would like to turn it around and ask that decisions are summarized after ml discussion.
[22:11:06] <jlec> That's least restrictive and most productive to not overlook something important.
[22:11:15] <dilfridge> or as rich0 described it, we are performing "suicide by social contract" here
[22:11:23] <dwfreed> ^
[22:11:31] <WilliamH> This is a tough one, because I agree with dwfreed and ulm
[22:12:15] <WilliamH> As soon as I see wltjr pipe up on a thread I tend to start ignoring the thread
[22:12:27] <Soap__> see also first bug
[22:12:46] <blueness> WilliamH: as already stated, there may be other solutions ;)
[22:12:46] <K_F> WilliamH: you can always ignore that specific individual though, by discard rule in sieve or whatnot
[22:12:51] <dilfridge> WilliamH: I do that too, and then some days later reluctantly read it because of potential council business
[22:12:51] <WilliamH> But on the other hand general moderation would be a lot of work for someone.
[22:13:30] <K_F> in this particular case, it seems that responses are made as long as people keeps replying to the emails
[22:13:40] <blueness> use of the lists is a privilege, not a right, if there is a general consensus, that privilege can be revoked, enough said
[22:13:48] <K_F> but at some point I'm wondering if we're not getting back to defining the scope of the various mailing lists
[22:14:33] <dwfreed> K_F: as mentioned by rich0, people could just end up unsubscribing too
[22:14:38] <blueness> guys, seeing as we've discussed this before, i'm not sure we need to discuss it again, are people ready for a vote?
[22:14:42] <dwfreed> K_F: and archives.gentoo.org has no ignore capability
[22:14:42] <K_F> and overall signal to noise ratio
[22:14:58] <dilfridge> s/could end up unsubscribing/did unsubscribe in significant numbers/  ?!
[22:15:34] <dilfridge> I suspect a vote is the best way to settle it
[22:15:52] <leio> the main point really is just the PR aspect imho
[22:16:04] <leio> (albeit a very important aspect imo)
[22:16:08] <tamiko> ^^^
[22:16:09] <dwfreed> ^ yes
[22:16:19] <WilliamH> ^^^
[22:16:20] <dwfreed> basically wltjr is becoming "the face of the mailing lists"
[22:16:42] <blueness> okay vote: do we want moderated lists?
[22:16:52] -*- WilliamH is more interested in the first bug 
[22:16:52] <dwfreed> and as evidenced by the ComRel timeout, he's perfectly willing to bypass those
[22:16:54] -*- blueness no
[22:16:59] <K_F> do we really want to have a discussion platform where dissenting views are banned?
[22:17:14] <leio> "I considered to become a gentoo developer, but then I saw all this hatred and discrimination on the mailing lists and I stepped back, I don't want to be part of this poisonous group"
[22:17:15] <Soap__> K_F: "right of admission reserved"
[22:17:27] <WilliamH> K_F: of course not.
[22:17:47] <leio> I'm not in favor of moderation, but something needs to be figured out, and I am looking squarely at comrel team for starters
[22:17:48] <dwfreed> K_F: moderation should be soley on the basis of technical merit; arguably wltjr's posts add nothing but personal agenda
[22:18:06] <blueness> guys back on track please, we are discussing whether we want a moderated list
[22:18:09] <dilfridge> It's not so much about dissenting views as about offtopic ravings
[22:18:19] <dwfreed> if it contributes nothing useful to the discussion, it gets moderated
[22:18:20] <K_F> blueness: no
[22:18:21] <dilfridge> and about doing *something*
[22:18:49] <WilliamH> dwfreed: My only concern is about the amount of work for someone...
[22:18:54] <K_F> dilfridge: to me that goes back to properly defining the scope of the mailing lists
[22:19:00] <WilliamH> dwfreed: moderation of the lists to me means like g-d-a
[22:19:07] <K_F> and a general S/N ratio discussion
[22:19:22] <WilliamH> dwfreed: so someone would have to approve all of the messages.
[22:19:23] <blueness> (i'll let the discussion go on a bit more but then i'd like to vote on this)
[22:19:40] <dwfreed> WilliamH: I think a 'trust bit' implementation would work well
[22:20:07] <dilfridge> oh please let's decide a fundamental question first, not go straight into implementation details
[22:20:22] <dwfreed> ^
[22:20:50] <jmbsvicetto> leio: So you're looking at the userrel side of comrel?
[22:21:11] <K_F> as for the PR question, anyone reading the archives understands that this is dissenting views and not one of Gentoo
[22:21:21] <K_F> but is that sufficient for moderation of that view?
[22:22:20] <jmbsvicetto> The person that makes most noise in a mailing list is not the same as the person that represents the view of those participating in the discussion in an ml
[22:22:41] <dwfreed> K_F: I'm not sure that they necessarily do
[22:23:08] <jmbsvicetto> This btw applies to recent discussions about users being able to participate in Gentoo matters speaking with an "official" role. That is not true
[22:23:15] <K_F> my first response is, stop replying to troll-bait
[22:23:30] <dilfridge> jmbsvicetto: does not parse
[22:23:33] <leio> jmbsvicetto: maybe; well, either, but in the devrel aspect we can boot it into the userrel aspect...
[22:24:03] <dwfreed> K_F: see eg https://archives.gentoo.org/gentoo-project/message/52c3960d83d95b0b7afaf55404652197
[22:24:22] <jmbsvicetto> dilfridge: recently people have been arguing that just by a user being able to send messages to an ml, send patches or have write privileges on repo, they gain an official role. That isn't true
[22:24:24] <dilfridge> K_F: I'm also not sure that people can differentiate
[22:24:39] <dilfridge> jmbsvicetto: yes, that's indeed bulshytt
[22:24:43] <jmbsvicetto> leio: devrel never took part in issues involving users
[22:25:00] <K_F> dwfreed: yes, I've seen it..
[22:25:14] <leio> jmbsvicetto: I meant that if a developer goes all bad PR spreading on the mailing list, we can at least strip developership and it becomes userrel.
[22:25:41] <jmbsvicetto> leio: yes, but this whole discussion is about a prior developer, thus a user
[22:25:55] <dilfridge> K_F: especially with wltjr blustering about "former developer, former trustee, ..." people do perceive him as someone "important"
[22:26:11] <blueness> guys can we bring this discussion to a conclusion please
[22:26:11] <blueness> are people ready to vote?
[22:26:12] <jmbsvicetto> leio: BTW, I'm by principle against discussions about a single case. We should strive to have general rules and not rules trying to target a specific case / person
[22:26:25] <NeddySeagoon> jmbsvicetto: List moderation ... for a single correspondent?
[22:26:40] <K_F> dilfridge: then we need to shape the definitions more than anything, it is clearly not an official Gentoo view comming from a user
[22:26:51] <ulm> blueness: what was the exact motion again?
[22:27:02] <K_F> ulm: moderation of lists
[22:27:16] <blueness> okay proceeding with the vote:  do we want moderation of gentoo-dev and gentoo-project
[22:27:17] <dilfridge> ok let's write this up a bit more specific
[22:27:17] -*- blueness no
[22:27:31] -*- K_F no
[22:27:35] -*- dilfridge yes
[22:27:49] <dilfridge> (assuming for non @gentoo.org addresses)
[22:28:16] <blueness> WilliamH: jlec ulm rich0
[22:28:53] -*- ulm no
[22:29:20] -*- jlec no
[22:29:28] <blueness> rich0 WilliamH
[22:29:36] <dilfridge> rich0 isnt here anymore
[22:29:50] -*- WilliamH no only because  of manual overhead
[22:30:13] <blueness> okay this motion fails.
[22:30:31] <blueness> what i recommend is that the next time before bringing thsi forward again, there is a better plan
[22:30:39] <blueness> maybe some prediscussion
[22:31:00] <blueness> finally 6. Open Floor
[22:31:05] <dilfridge> well that kind of requires that people participate
[22:31:22] <blueness> dilfridge: maybe a discussion on gentoo-core?
[22:31:22] <K_F> dol-sen: if you're still here, I'd like to know if there is anything we can do from council to move OpenPGP verification of the gentoo repository in place
[22:31:48] <K_F> dol-sen: i.e to get gkeys fully implemented et al
[22:32:52] <dwfreed> portage generation and validation of MetaManifests is the biggest thing
[22:32:52] <blueness> okay if there's nothing more, meeting over
[22:33:06] <K_F> blueness: that is for open floor
[22:33:16] <blueness> sorry
[22:33:30] <leio> what happens about sparc/ia64
[22:33:45] <dilfridge> what happens about ppc
[22:33:51] -*- WilliamH says move them to dev or exp
[22:34:02] <Soap__> yes please
[22:34:08] <Soap__> lets move sparc/ia64 to dev
[22:34:15] <Soap__> ppc has received a formal complaint
[22:34:20] <Soap__> so that is out of the question
[22:34:25] <K_F> leio: we seem to be dropping them from security supported architectures at least (sparc that is, ia64 has never been officially supported)
[22:34:32] <Soap__> to date noone from ia64/sparc has replied
[22:35:10] <dilfridge> zlogene
[22:35:32] <K_F> dwfreed: the code for that is mostly written, isn't it? we were waiting for some signature generation on the rsync master / key generation iirc?
[22:35:35] <Soap__> well, zlogene complained, but said himself he doesnt actually do anything for the archs
[22:35:44] <WilliamH> I need to bail, but count me as voting yes for both sparc and ia64 going to dev
[22:35:57] <dwfreed> K_F: if it is, nobody's pointed it out to me
[22:36:19] <Soap__> complaining about moving to dev is one thing
[22:36:26] <Soap__> doing the actual work is another
[22:36:32] <blueness> guys, i have to run, dilfridge can you  send me the logs please
[22:36:36] <dilfridge> will do
[22:36:41] <K_F> dwfreed: it was part of last year's GSoC
[22:36:42] <blueness> ty
[22:36:49] <dwfreed> K_F: it didn't finish
[22:38:54] <dilfridge> ok so do we still have anything to discuss?
[22:39:19] <Soap__> so no vote on ia64/sparc -> dev?
[22:39:39] <K_F> Soap__: if voting it should be brought up in the official agenda
[22:39:52] <dilfridge> Soap__: well, I personally recommend that you go ahead with the dekeywording plan
[22:40:05] <dilfridge> and if the result is too big, mask some more useflags
[22:40:21] --> toralf (~toralf@x4e363794.dyn.telefonica.de) hat #gentoo-council betreten
[22:40:26] <Soap__> dilfridge: https://github.com/gentoo/gentoo/pull/4614
[22:41:06] <dol-sen> K_F, I'm back for a few
[22:41:10] <dilfridge> I know that, but it doesnt look finished
[22:41:14] <dilfridge> :P
[22:41:20] <K_F> dol-sen: is there anythign we can do to move things along?
[22:41:20] <Soap__> dilfridge: still
[22:41:27] <Soap__> xmw seems to be against
[22:41:34] <Soap__> and at some point I'd like vote on it
[22:41:45] <leio> that'd be ppc then, afaiu
[22:41:45] <Soap__> otherwise I will proceed unilaterally for some CATs
[22:41:47] <K_F> dol-sen: what is needed in terms of contributions to get it done?
[22:41:52] <dol-sen> yeah, poke Robin to get the key cards, new infra keys established
[22:42:20] <dol-sen> we also need more testing bug-fixes for gkeys-gpg
[22:42:22] <dilfridge> Soap__: I hate to be the guy insisting on procedures, but if you want a vote it needs to be on the agenda beforehand
[22:42:37] <Soap__> dilfridge: we can table it for the next time
[22:42:50] <dilfridge> ok anything else
[22:43:00] <dol-sen> and most importantly we need permanent home and setup to keep the gentoo-devs seeds up to date
[22:43:01] <K_F> dol-sen: any testing procedure we can recommend?
[22:43:25] <K_F> dol-sen: right, which is currently being done on vulture and distributed on api.g.o
[22:43:47] <dol-sen> yeah, set .git/config to point to the gkeys-gpg command and test git log --show-signature
[22:43:53] <dilfridge> K_F: is this technical discussion necessary now?
[22:44:04] <dol-sen> K_F, yes
[22:44:40] <K_F> dilfridge: I'm quite ashamed we don't have OpenPGP verification in place already, so whatever can be done to get it in place sooner rather than later is necessary
[22:45:12] <dilfridge> well, while I agree that Gentoo is a bit stone-age there, I'm not sure what the council can contribute
[22:45:17] <K_F> but indeed, we can continue it on MLs etc, but we *need* to get it in place
[22:45:23] <dol-sen> I'm wondering if I could even get a buildbot slave running somewhere, then I could run a buildbot out of infra where it is easier to configure to push to api.g.o
[22:45:39] <dol-sen> and set the mast to run it on a timer
[22:45:56] <dol-sen> then it'd have a web interface of the runs, to see for errors, etc.
[22:46:01] -*- dilfridge has this distinct feeling that an overcomplicated solution is in the works
[22:46:46] <dilfridge> you know, we could, like, go from stone age to iron first, and dont immediately need superconductors
[22:47:03] <dol-sen> nah, but I'm tired of having to manually ssh in to vulture, make sure gpg-agent forwarding it set up correctly, in order to update them
[22:47:27] <dol-sen> and I don't always have time for that
[22:47:45] <dilfridge> anyway, I think we can close the council meeting now, before attendance and attention even falls further
[22:47:46] <K_F> dol-sen: in all fairness, that part is acceptable , I'm more worried about the signatures and validation not being done as of yet
[22:47:58] <K_F> dilfridge: wfm
[22:48:01] <dilfridge> 3
[22:48:04] <dilfridge> 2
[22:48:05] <dol-sen> besides buildbot is not that difficult
[22:48:07] <dilfridge> 1
[22:48:11] <dilfridge> -bang-
[22:48:15] <dilfridge> meeting closed