2017-05-14 00:37:14-!- Irssi: #gentoo-council: Total of 43 nicks [7 ops, 0 halfops, 0 voices, 36 normal]
2017-05-14 00:37:16-!- mode/#gentoo-council [+o K_F] by ChanServ
2017-05-14 00:39:42-!- Irssi: Join to #gentoo-council was synced in 152 secs
2017-05-14 13:19:37-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 16:19:17-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 17:16:10-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 17:26:05-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 18:50:46-!- mode/#gentoo-council [+o blueness_] by ChanServ
2017-05-14 19:07:02-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 19:11:46<@blueness> hi everyone, 2:00 until the meeting, please note, for reasons outside of my control, my internet has been flakey all morning
2017-05-14 19:12:06< dwfreed> go to the library?
2017-05-14 19:12:29 * K_F just use mobile connection as backup in such cases
2017-05-14 19:12:30< dwfreed> if it's one thing universities are usually really good at, it's having a great internet connection
2017-05-14 19:13:10<@K_F> blueness: maybe run an irssi session on another host that you can reconnect to to keep context?
2017-05-14 19:14:52<@blueness> i’m stuck home (baking), i’ll get an irc for my phone in case it goes down again
2017-05-14 19:15:36 * K_F use ssh from phone into home regularly, but in this case :p
2017-05-14 19:15:56<@K_F> blueness: if you dont want a local client, can likely just use webchat
2017-05-14 19:16:00< dwfreed> yeah, I'd fire up irssi on woodpecker and ssh to that
2017-05-14 19:16:18<@K_F> dwfreed: yup
2017-05-14 19:17:29<@blueness> K_F: yeah a web client will work
2017-05-14 19:17:30<@blueness> i’m so slow at texting though
2017-05-14 19:17:56<@K_F> blueness: well, its just a backup :)
2017-05-14 19:18:06<@blueness> K_F: yeah, the line is fine now
2017-05-14 19:18:24<@blueness> K_F: at the very least i’ll be able to say what happened
2017-05-14 19:18:37<@K_F> yup
2017-05-14 19:18:39<@blueness> we had a flash shower at the same time my line went down
2017-05-14 19:18:56<@K_F> those are always fun
2017-05-14 20:04:09-!- mode/#gentoo-council [+o helium-3] by ChanServ
2017-05-14 20:20:30<@blueness> i’m still here!
2017-05-14 20:20:35<@blueness> 40 minutes until the meeting
2017-05-14 20:20:48<@blueness> agenda -> http://dpaste.com/2Y2NZ7N
2017-05-14 20:22:13< mgorny> blueness: do you think i will be needed? The concert starts then xP
2017-05-14 20:23:25<@K_F> mgorny: are there any XP machines not hit by WannaCry? :p
2017-05-14 20:24:34<@blueness> mgorny: not really
2017-05-14 20:24:45<@blueness> what concert?
2017-05-14 20:26:56< dwfreed> dilfridge: an added comment re guidelines for council summaries: voting results should list who voted what way, since by the nature of how meetings are done, all votes are effectively by roll call
2017-05-14 20:27:35<@dilfridge> I dont really see any point in that... the details are in the log
2017-05-14 20:30:54< dwfreed> the summaries are arguably the equivalent of meeting minutes (where the log is a full transcript; they are different concepts); basically ever parliamentary body records how members voted in minutes when it is possible to determine that without ambiguity (ie, anything other than voice vote)
2017-05-14 20:31:21< dwfreed> s/ever p/every p/
2017-05-14 20:33:51<@blueness> i’m with dilfridge on this one, details are in the log
2017-05-14 20:34:22<@blueness> i think it is sufficient to say “passed” or “unanimously passed” or “failed” or “unanimously failed”
2017-05-14 20:34:47<@K_F> I can see the value in it for tracking individual members' voting record over time etc
2017-05-14 20:34:56<@K_F> but I'm not sure if that is worthwhile to begin with
2017-05-14 20:35:47< dwfreed> there's always some political aspects to any elected body
2017-05-14 20:37:19< dwfreed> even if it comes down to "how does this person vote on the technical aspects that matter to me"
2017-05-14 20:41:58<@K_F> dwfreed: can argue that the rationale for the voting is an important input factor to that so should read log anyways
2017-05-14 20:50:21< mgorny> blueness: TSA @ 90 yrs of radio poznan
2017-05-14 20:50:52<@blueness> mgorny: go enjoy
2017-05-14 20:50:59< Soap__> blueness: you should really look into disabling OSX's autocorrect
2017-05-14 20:51:17<@blueness> Soap__: why?
2017-05-14 20:51:25< Soap__> because unicode quotes are awful
2017-05-14 20:51:47< Soap__> I know Apple wanted to be nice and thought they were clever
2017-05-14 20:51:48<@blueness> that’s not autocorrect
2017-05-14 20:52:30< dwfreed> it's part of the autocorrect options
2017-05-14 20:53:09<@K_F> unless it messes up quotations for explicit commands, I fail to see much issue with it
2017-05-14 20:53:38< Soap__> which in latex, it generally does
2017-05-14 20:54:07< dwfreed> setting lives at System Preferences -> Keyboard -> Text
2017-05-14 20:54:11<@blueness> test's
2017-05-14 20:54:15< dwfreed> woo
2017-05-14 20:54:16< Soap__> better
2017-05-14 20:54:18< Soap__> :P
2017-05-14 20:55:35<@blueness> 5 minutes ''''
2017-05-14 20:55:36<@blueness> :)
2017-05-14 20:55:43< Soap__> now double quotes
2017-05-14 20:55:49<@blueness> """
2017-05-14 20:56:02< Soap__> see, now everyone is happy :)
2017-05-14 20:56:10<@blueness> i'm not
2017-05-14 20:56:12<@blueness> :(
2017-05-14 20:56:27< Soap__> Why’s that so?
2017-05-14 20:57:11<@jlec> Hi guys
2017-05-14 20:57:15<@jlec> I am back in 4
2017-05-14 20:58:06<@blueness> i actually cna't see the difference between smart quotes and regular
2017-05-14 20:58:07<@blueness> what do they look like at your end?
2017-05-14 20:58:08<@blueness> k
2017-05-14 20:58:29 * WilliamH is here
2017-05-14 20:59:27<@blueness> WilliamH: that's debatable
2017-05-14 20:59:48<@dilfridge> " “ ”
2017-05-14 20:59:56<@K_F> blueness: https://download.sumptuouscapital.com/gentoo/tmp/Screenshot%20from%202017-05-14%2020-58-33-1.png
2017-05-14 21:00:19<@blueness> K_F: oh wierd
2017-05-14 21:00:29<@WilliamH> heh
2017-05-14 21:00:39<@WilliamH> blueness: why do you say that? ;-)
2017-05-14 21:00:42<@blueness> K_F: thanks for that screen shot
2017-05-14 21:00:49<@blueness> WilliamH: just being silly
2017-05-14 21:01:00<@WilliamH> blueness: heh
2017-05-14 21:02:02<@blueness> we're waiting for jlec, i'm going to feed my dog and we'lls tart in 5
2017-05-14 21:02:11<@jlec> I am here
2017-05-14 21:02:16< Soap__> blueness: I hope you understand now why I dont like them :P
2017-05-14 21:03:04<@rich0> FYI - I need to leave a bit before 20:00
2017-05-14 21:05:00-!- mode/#gentoo-council [+o blueness] by ChanServ
2017-05-14 21:09:38<@blueness> okay let's start
2017-05-14 21:09:40<@blueness> --- start ---
2017-05-14 21:09:42<@blueness> ping blueness dilfridge jlec K_F rich0 ulm williamh
2017-05-14 21:09:43<@blueness> ping  dilfridge jlec K_F rich0 ulm williamh
2017-05-14 21:09:54<@dilfridge> here
2017-05-14 21:09:57 * K_F here
2017-05-14 21:09:57 * WilliamH is here
2017-05-14 21:10:02 * jlec here
2017-05-14 21:10:05 * rich0 here
2017-05-14 21:10:08 * ulm here
2017-05-14 21:10:12 * dilfridge here
2017-05-14 21:10:31<@blueness> okay agenda at http://dpaste.com/2Y2NZ7N
2017-05-14 21:11:02<@blueness> 1. Roll call - looks like everyone is present
2017-05-14 21:11:19<@blueness> if the agenda looks okay, let's move on to item 2
2017-05-14 21:11:41<@blueness> 2. Discussion on Guidelines for the council summaries - https://archives.gentoo.org/gentoo-project/message/7d6a15b12347ce173609e0f50595fbc0
2017-05-14 21:11:55<@dilfridge> ok so
2017-05-14 21:12:01<@blueness> dilfridge: that's yours so do you want to start commenting?
2017-05-14 21:12:08<@dilfridge> as said in the e-mail, this is not something we need to vote on
2017-05-14 21:12:16<@dilfridge> it's just a list of suggestions
2017-05-14 21:12:26<@dilfridge> about the reasons
2017-05-14 21:12:37<@blueness> dilfridge: i'm okay with all your suggestions but what's the problem?
2017-05-14 21:12:43<@dilfridge> no problem at all
2017-05-14 21:13:00<@rich0> The only suggestion I'd make is that rather than posting agendas/summaries in emails, it might make more sense to link them.
2017-05-14 21:13:02<@K_F> blueness: reading through the older summaries leaves something wanting, having guidelines on it seems like a good idea
2017-05-14 21:13:03<@dilfridge> I'm reading old summaries, and that turns up all sorts of problems in those
2017-05-14 21:13:06<@rich0> To the wiki...
2017-05-14 21:13:18<@K_F> ini particular broken links etc in the historical ones making it difficult to get context
2017-05-14 21:13:23<@rich0> Certainly for summaries/etc.  Agendas are probably more open to debate, since I don't think we log those on the wiki.
2017-05-14 21:13:25<@jlec> dilfridge: I like it.
2017-05-14 21:13:32<@dilfridge> in particular, broken links are a problem,
2017-05-14 21:13:36<@rich0> But, in general I'm fine with it.
2017-05-14 21:13:38<@ulm> maybe s/A link to the meeting agenda/The meeting agenda or a link to it/ in item 2?
2017-05-14 21:13:49<@dilfridge> and stuff gets forgotten if it was decided between meetings and isnt mentioned in the log / summary
2017-05-14 21:13:58<@rich0> Links should be to places that are fairly durable though.
2017-05-14 21:13:58<@ulm> otherwise all that is fine
2017-05-14 21:13:59<@blueness> rich0: i've always put the agenda at the top of my summaries
2017-05-14 21:14:05<@dilfridge> works for me
2017-05-14 21:14:07<@rich0> Links to agendas in your dev web space not so good...
2017-05-14 21:14:11<@K_F> ulm: in most cases the agenda should be covered by the summary itself as it should follow it to begin with
2017-05-14 21:14:18<@blueness> links to mail archives are okay
2017-05-14 21:14:21<@rich0> I personally use the agenda to create the summary.
2017-05-14 21:14:32<@WilliamH> rich0: ++
2017-05-14 21:14:37<@dilfridge> so if that's ok for you I'll just update the council page with a slightly amended version of the mail
2017-05-14 21:14:54<@ulm> also 3 is due to a technical limitation
2017-05-14 21:14:55<@dilfridge> or a subpage, weherever
2017-05-14 21:14:58<@WilliamH> for me personally it is easier to use the agenda to create the summary
2017-05-14 21:15:08<@WilliamH> list each item and what happens with it.
2017-05-14 21:15:08<@ulm> once that's fixed we won't need 3 any more
2017-05-14 21:15:15<@dilfridge> ulm: yes, but...
2017-05-14 21:15:36<@ulm> I agree that for the time being attachments should be avoided
2017-05-14 21:15:38<@dilfridge> anyway, you've all seen it, I dont think we need a long discussion
2017-05-14 21:15:50<@rich0> Yup, I'm fine with it in general.
2017-05-14 21:16:07<@blueness> dilfridge: yeah sounds good to me
2017-05-14 21:16:19<@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
2017-05-14 21:16:32<@K_F> but I agree we likely don't need a vote on the specific guidelines
2017-05-14 21:16:46<@K_F> maybe we should write a wiki page or something on it and keep up to date, though?
2017-05-14 21:17:01<@K_F> maybe under Chairing role or something
2017-05-14 21:17:22<@blueness> i think we're in agreement, dilfridge add the stuff to the wiki and let's move on
2017-05-14 21:17:27<@dilfridge> ++
2017-05-14 21:17:29<@K_F> responsibilities of the meeting chair
2017-05-14 21:17:57<@blueness> K_F: let's not slide into defining full roles for chair though
2017-05-14 21:18:03<@blueness> okay moving on
2017-05-14 21:18:14<@blueness> Discussion on arches.desc & GLEP 72
2017-05-14 21:18:24<@blueness> https://archives.gentoo.org/gentoo-project/message/a0babd1fcfd6471bfa9afd76e51a4c3b
2017-05-14 21:18:32<@blueness> https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
2017-05-14 21:18:45<@blueness> dilfridge: that's you again, do you want to introduce us to this glep
2017-05-14 21:18:51<@dilfridge> ok
2017-05-14 21:19:03<@dilfridge> so, at the moment we have three problems
2017-05-14 21:19:38<@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
2017-05-14 21:20:08<@dilfridge> tools like eshowkw solve that by checking if an arch has stable profiles in profiles.desc, but that's not a good solution
2017-05-14 21:20:27<@dilfridge> second, we have arches like m68k
2017-05-14 21:20:54<@dilfridge> where stable keywords exist in the tree, but the arch is not stable (per council decision)
2017-05-14 21:21:30<@dilfridge> this means that all profiles must be set to exp, and effectively repoman checking is turned off
2017-05-14 21:21:48<@dilfridge> even though repoman checking would make sense for ~m68k
2017-05-14 21:21:57<@dilfridge> (keeping a consistent unstable deptree)
2017-05-14 21:22:17<@dilfridge> third, it's hard to prepare an arch for stabilization,
2017-05-14 21:22:47<@dilfridge> basically the arch team has to make a fully consistent deptree and then switch a profile to stable at one point in time
2017-05-14 21:22:55<@dilfridge> which is not easy
2017-05-14 21:23:16<@dilfridge> the intention of the GLEP is to address these three things
2017-05-14 21:23:44<@dilfridge> it introduces one new file, called profiles/arches.desc, in analogy to profiles/profiles.desc
2017-05-14 21:24:11<@dilfridge> lines with space-separated columns
2017-05-14 21:24:22<@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
2017-05-14 21:24:45<@WilliamH> So, a question from me too.
2017-05-14 21:24:56<@dilfridge> blueness: true, but the next developer will have that switched off and inadvertently break the deptree again
2017-05-14 21:25:16< Soap__> dilfridge: will that require devs to KEYWORDREQ m68k then?
2017-05-14 21:25:17<@K_F> dilfridge: can't that be made into a question of defaulting repoman to -d ?
2017-05-14 21:25:20<@WilliamH> If w e introduce arches.desc, why would we still need profiles.desc?
2017-05-14 21:25:53<@dilfridge> ok one after the other
2017-05-14 21:26:08<@blueness> dilfridge: i'm confused as to how repoman would use arches.desc
2017-05-14 21:27:02<@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,
2017-05-14 21:27:34<@dilfridge> it provides the classification of dev / exp, and thereby the possibility to "turn off" checking.
2017-05-14 21:28:31<@dilfridge> Soap__: KEYWORDREQ for m68k, yes if repoman complains on broken deptree (and technically you should file them now, too)
2017-05-14 21:28:33<@ulm> also we cannot remove profiles.desc without an EAPI bump
2017-05-14 21:28:50<@ulm> even if we wanted
2017-05-14 21:29:06<@dilfridge> K_F: defaulting repoman to -d solves a different problem
2017-05-14 21:29:20<@dilfridge> blueness: give me another 2-3 lines to describe it
2017-05-14 21:29:23< Soap__> dilfridge: i.e. more ppc/ia64/sparc?
2017-05-14 21:29:53<@dilfridge> Soap__: just introducing the file doesnt change anything, the default settings mirror what we have now
2017-05-14 21:30:02<@blueness> dilfridge: k
2017-05-14 21:30:28<@dilfridge> so it introduces three states per architecture
2017-05-14 21:31:02<@WilliamH> dilfridge: can't you answer 2 an 3 above though by some combinations of the second and third columns of  arches.desc?
2017-05-14 21:31:02<@dilfridge> "stable" is the default and the behaviour we have now... amd64 and ~amd64 describe two different deptrees, which both have to be consistent
2017-05-14 21:31:52<@dilfridge> "mixed" means repoman treats m68k internally as ~m68k, and checks consistency only for ~m68k
2017-05-14 21:32:17<@dilfridge> "unstable" means mips is invalid and generates an error, and consistency is checked for ~mips
2017-05-14 21:34:02<@blueness> .... thinking ....
2017-05-14 21:34:25<@blueness> dilfridge: suppose i wanted to transition mips to be like m68k, how would i do so??
2017-05-14 21:34:26<@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.
2017-05-14 21:34:28< dwfreed> btw, repoman -d is only dev profiles, you need -ey for exp profiles too (annoyingly -e takes an option, -d does not)
2017-05-14 21:34:51<@ulm> dilfridge: we don't want a column specifying if the arch is security supported?
2017-05-14 21:35:00<@dilfridge> ulm: we can add that too
2017-05-14 21:35:14<@dilfridge> blueness: you add a line stating "mips mixed"
2017-05-14 21:36:08<@blueness> dilfridge: would you hit inconsistencies?
2017-05-14 21:36:15<@dilfridge> blueness: in what sense?
2017-05-14 21:36:45<@blueness> dilfridge: suppose you add only some mips keywords, and some deps are only ~mips, would that show up?
2017-05-14 21:37:13<@dilfridge> in that "mixed" setting, by default repoman would accept that just fine
2017-05-14 21:37:16<@blueness> ie you add some stable mips keywords to an ebuild, but that ebuild has some ~mips only dependencies, would that throw an error?
2017-05-14 21:37:30< dwfreed> no
2017-05-14 21:37:36< dol-sen> blueness no
2017-05-14 21:37:42<@blueness> got it
2017-05-14 21:37:51<@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
2017-05-14 21:38:08< dol-sen> it would allow you to work on making enough ebuilds with stable arch keywords to allow a change to stable
2017-05-14 21:38:09<@dilfridge> which is useful for the arch team to prepare the stable deptree
2017-05-14 21:38:36< dwfreed> "mixed" has the expectation that the user has (either by profile or by make.conf) ACCEPT_KEYWORDS="~${ARCH}"
2017-05-14 21:38:47<@dilfridge> yes
2017-05-14 21:39:32< dwfreed> (also same would necessarily apply for "unstable")
2017-05-14 21:39:43<@dilfridge> obviously, yes
2017-05-14 21:41:44<@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
2017-05-14 21:42:59< dwfreed> stable/dev/exp on profiles has no bearing on depgraph consistency itself; it only controls what flags enable repoman checking of that consistency
2017-05-14 21:43:58<@blueness> i'm wondering if we need to do anything with catalyst
2017-05-14 21:44:08< leio> as soon as people stopped just always passing -d, this became useless
2017-05-14 21:44:13<@blueness> because it also respects profiles.desc
2017-05-14 21:44:42< 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
2017-05-14 21:44:44<@dilfridge> blueness: I can't imagine that this affects catalyst, because it doesnt affect emerge
2017-05-14 21:44:54<@dilfridge> only repoman and similar qa tools
2017-05-14 21:45:41 * WilliamH agrees with dilfridge 
2017-05-14 21:45:49< leio> (I don't know about stage building to know why such a stable marking is necessary really)
2017-05-14 21:45:49<@WilliamH> I don't see how this would affect catalyst
2017-05-14 21:46:02< dol-sen> it wouldn't no
2017-05-14 21:46:08<@blueness> dilfridge: k
2017-05-14 21:46:09<@blueness> WilliamH: catalyst reads profiles.desc
2017-05-14 21:46:28<@WilliamH> blueness: Why?
2017-05-14 21:46:33< Soap__> also, we're back at the ppc/ia64/sparc mess
2017-05-14 21:46:38<@blueness> 1 sec
2017-05-14 21:47:00<@blueness> WilliamH: oh wait, its not for exp/dev/stable, but for legitimate profiles
2017-05-14 21:47:35< Soap__> blueness: so the stable keywords argument is moot?
2017-05-14 21:47:44<@WilliamH> blueness: ok, so we are good then.
2017-05-14 21:48:39<@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
2017-05-14 21:49:07<@blueness> Soap__: i think if we drop ppc to mixed, we relieve the problem we've been discussing on the list
2017-05-14 21:49:31<@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.
2017-05-14 21:49:35<@WilliamH> blueness: hrm, that might be an error in itself, but that's another topic for another time.
2017-05-14 21:49:39<@ulm> dilfridge: what about stabilisation tools that allow an "all" keyword? would they act on all stable, or on stable+mixed?
2017-05-14 21:49:55<@dilfridge> heh
2017-05-14 21:49:59<@dilfridge> good question
2017-05-14 21:50:09<@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.
2017-05-14 21:50:24<@dilfridge> I'd suggest: by default, act on "stable"; with switch, act on "stable+mixed"
2017-05-14 21:50:42<@WilliamH> dilfridge: sounds reasonable.
2017-05-14 21:51:05<@dilfridge> same idea as with repoman, a switch for "arch team work"
2017-05-14 21:51:05<@ulm> e.g. ekeyword allows all, and so does ebuild-mode
2017-05-14 21:53:08<@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...
2017-05-14 21:53:19< leio> ALLARCHES should be just "only stabilize if older version has stable keywords" and it doesn't matter if stable or stable+mixed
2017-05-14 21:54:04<@WilliamH> leio: that's a good idea too.
2017-05-14 21:54:17<@WilliamH> leio: base it on the status of older versions of the package.
2017-05-14 21:54:24<@ulm> but complicated, because the tool has to look into other ebuilds then
2017-05-14 21:54:46< leio> but that's how keywording works, across versions
2017-05-14 21:55:00<@ulm> true
2017-05-14 21:55:11<@K_F> ulm: at the time of stabilization, eshowkw etc will do that anyways
2017-05-14 21:56:07<@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?
2017-05-14 21:56:17<@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
2017-05-14 21:56:38<@dilfridge> blueness: "mixed" assumes that users only run ~arch
2017-05-14 21:56:41<@ulm> K_F: +1
2017-05-14 21:56:53<@dilfridge> and that whatever stable keywords exist are "internal" for the arch team
2017-05-14 21:57:01<@dilfridge> K_F: works for me
2017-05-14 21:57:20< 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 ;)
2017-05-14 21:57:23<@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?
2017-05-14 21:57:35<@ulm> dilfridge: "premium_unstable"? :)
2017-05-14 21:57:47<@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
2017-05-14 21:57:48<@dilfridge> blueness: essentially yes, for your own fun and profit
2017-05-14 21:57:54<@dilfridge> ulm: with extra legroom, yes
2017-05-14 21:58:08<@blueness> dilfridge: that is the way vapier is treaking m68k
2017-05-14 21:58:31<@dilfridge> right, and that's what it is modelled after
2017-05-14 21:59:00<@WilliamH> So what do we want to do with ia64 and sparc?
2017-05-14 21:59:17<@dilfridge> different topic
2017-05-14 21:59:27<@blueness> okay guys, we're not ready for any vote now, and we should move on
2017-05-14 21:59:29<@dilfridge> so how about, the discussion of GLEP 72 is tabled for next time
2017-05-14 21:59:42<@blueness> dilfridge: yes, let's table it
2017-05-14 21:59:55<@K_F> dilfridge: thanks for working on it
2017-05-14 22:00:09<@dilfridge> np
2017-05-14 22:00:10<@blueness> ditto, thanks dilfridge
2017-05-14 22:00:36<@blueness> next4. Open bugs with council involvement [4]
2017-05-14 22:00:47<@blueness> Bugs 618254, 616206, 565566
2017-05-14 22:00:53<@blueness> let's to through each
2017-05-14 22:01:03<@blueness> bug #618254
2017-05-14 22:01:16<@blueness> hmmm no wilikins
2017-05-14 22:01:17<@dilfridge> bug 618254
2017-05-14 22:01:24<@ulm> secret bug
2017-05-14 22:01:26<@K_F> blueness: its restricted by group
2017-05-14 22:01:30<@blueness> ah yes!
2017-05-14 22:01:36<@K_F> its likely not an issue for the public channel
2017-05-14 22:01:58<@jlec> I think it is ComRel business
2017-05-14 22:02:02<@K_F> arguably that isn't a council...
2017-05-14 22:02:04<@K_F> exactly
2017-05-14 22:02:15< Soap__> no
2017-05-14 22:02:19<@blueness> K_F: i agree, we don't need to discuss that now
2017-05-14 22:02:26< Soap__> it was explicitly requested that the council votes on it
2017-05-14 22:02:44<@ulm> Soap__: not now and not in public
2017-05-14 22:03:22<@blueness> okay how about we deal with that one by posting on the bug before next meeting
2017-05-14 22:03:33<@blueness> so let's move on
2017-05-14 22:04:01<@blueness> Bug 616206 - EAPI 6 reapproval
2017-05-14 22:04:03< willikins> blueness: https://bugs.gentoo.org/616206 "EAPI 6 reapproval"; Gentoo Hosted Projects, PMS/EAPI; IN_P; ulm:council
2017-05-14 22:04:15<@K_F> that has already been voted on, so it is just to record results in summary
2017-05-14 22:04:17<@jlec> Approved
2017-05-14 22:04:23<@dilfridge> that's already done and is hereby referenced
2017-05-14 22:04:24<@blueness> yeah i think we can close that no?
2017-05-14 22:04:26<@dilfridge> ++
2017-05-14 22:04:29<@ulm> yep, that can be closed
2017-05-14 22:04:48<@ulm> the PMS version is released and also online
2017-05-14 22:05:05<@K_F> but goes back to initial summary discussion for proper recording, I like the idea of keeping open until next meeting etc
2017-05-14 22:05:31<@K_F> and also the form of voting in-between meetings, not waiting for next
2017-05-14 22:06:10<@blueness> i just closed it
2017-05-14 22:06:11<@blueness> Bug 565566 - New ChangeLogs are in chronological order
2017-05-14 22:06:11<@blueness> i'm not sure what we need to do for that one
2017-05-14 22:06:13< willikins> blueness: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
2017-05-14 22:06:30<@K_F> blueness: I don't believe there is anything new for us on that one
2017-05-14 22:06:37<@WilliamH> blueness: we are still waiting for infra
2017-05-14 22:06:40<@blueness> yeah
2017-05-14 22:06:43< NeddySeagoon> Announce the results of votes between meeings at the next meetin, so that there is a record in the log
2017-05-14 22:06:44<@ulm> I'm not aware of any progress
2017-05-14 22:07:05<@K_F> NeddySeagoon: yes, thats why it is kep open until now and mentioned
2017-05-14 22:07:13<@ulm> I count 7 yes votes. So this has been approved unanimously by the council.
2017-05-14 22:07:15<@K_F> NeddySeagoon: it'll be in summary
2017-05-14 22:07:16<@blueness> NeddySeagoon: okay regarding Bug 616206 - EAPI 6 reapproval -> unanimously passed
2017-05-14 22:07:16< willikins> blueness: https://bugs.gentoo.org/616206 "EAPI 6 reapproval"; Gentoo Hosted Projects, PMS/EAPI; IN_P; ulm:council
2017-05-14 22:07:49<@blueness> okay guys, let's move on to 5. Mailing list moderation
2017-05-14 22:08:00<@blueness> https://archives.gentoo.org/gentoo-project/message/ad3bbffe2286cced97b64571edc1245d
2017-05-14 22:08:24<@blueness> my 2 cents, no need for moderation of the lists
2017-05-14 22:08:36<@K_F> blueness: I tend to agree
2017-05-14 22:08:39<@ulm> we had discussed that in december already
2017-05-14 22:08:50<@blueness> yep, this keeps resurging
2017-05-14 22:08:53< dwfreed> I think we need to do something
2017-05-14 22:09:04<@blueness> dwfreed: why and like what?
2017-05-14 22:09:17< dwfreed> as to why, that can be answered with one word: wltjr
2017-05-14 22:09:39<@blueness> dwfreed: there may be other solutions
2017-05-14 22:09:43<@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.
2017-05-14 22:09:58<@K_F> I don't see an overall level of emails that results in a need for moderation of the lists
2017-05-14 22:10:11< dwfreed> I'm not saying every post needs to be moderated
2017-05-14 22:10:18<@dilfridge> wltjr is slowly dominating the public perception of gentoo
2017-05-14 22:10:23< dwfreed> or even every post from not-devs
2017-05-14 22:10:28<@ulm> basically it's one single person causing trouble there
2017-05-14 22:10:28< dwfreed> but that ^^^ is very important
2017-05-14 22:10:36<@ulm> not a case for general moderation
2017-05-14 22:10:36<@jlec> I personally would like to turn it around and ask that decisions are summarized after ml discussion.
2017-05-14 22:11:04<@jlec> That's least restrictive and most productive to not overlook something important.
2017-05-14 22:11:14<@dilfridge> or as rich0 described it, we are performing "suicide by social contract" here
2017-05-14 22:11:22< dwfreed> ^
2017-05-14 22:11:30<@WilliamH> This is a tough one, because I agree with dwfreed and ulm
2017-05-14 22:12:14<@WilliamH> As soon as I see wltjr pipe up on a thread I tend to start ignoring the thread
2017-05-14 22:12:26< Soap__> see also first bug
2017-05-14 22:12:44<@K_F> WilliamH: you can always ignore that specific individual though, by discard rule in sieve or whatnot
2017-05-14 22:12:44<@blueness> WilliamH: as already stated, there may be other solutions ;)
2017-05-14 22:12:49<@dilfridge> WilliamH: I do that too, and then some days later reluctantly read it because of potential council business
2017-05-14 22:12:50<@WilliamH> But on the other hand general moderation would be a lot of work for someone.
2017-05-14 22:13:29<@K_F> in this particular case, it seems that responses are made as long as people keeps replying to the emails
2017-05-14 22:13:38<@blueness> use of the lists is a privilege, not a right, if there is a general consensus, that privilege can be revoked, enough said
2017-05-14 22:13:46<@K_F> but at some point I'm wondering if we're not getting back to defining the scope of the various mailing lists
2017-05-14 22:14:32< dwfreed> K_F: as mentioned by rich0, people could just end up unsubscribing too
2017-05-14 22:14:37<@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?
2017-05-14 22:14:41< dwfreed> K_F: and archives.gentoo.org has no ignore capability
2017-05-14 22:14:41<@K_F> and overall signal to noise ratio
2017-05-14 22:14:57<@dilfridge> s/could end up unsubscribing/did unsubscribe in significant numbers/  ?!
2017-05-14 22:15:33<@dilfridge> I suspect a vote is the best way to settle it
2017-05-14 22:15:51< leio> the main point really is just the PR aspect imho
2017-05-14 22:16:03< leio> (albeit a very important aspect imo)
2017-05-14 22:16:07< tamiko> ^^^
2017-05-14 22:16:07< dwfreed> ^ yes
2017-05-14 22:16:17<@WilliamH> ^^^
2017-05-14 22:16:19< dwfreed> basically wltjr is becoming "the face of the mailing lists"
2017-05-14 22:16:41<@blueness> okay vote: do we want moderated lists?
2017-05-14 22:16:51 * WilliamH is more interested in the first bug 
2017-05-14 22:16:51< dwfreed> and as evidenced by the ComRel timeout, he's perfectly willing to bypass those
2017-05-14 22:16:52 * blueness no
2017-05-14 22:16:57<@K_F> do we really want to have a discussion platform where dissenting views are banned?
2017-05-14 22:17:12< 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"
2017-05-14 22:17:14< Soap__> K_F: "right of admission reserved"
2017-05-14 22:17:26<@WilliamH> K_F: of course not.
2017-05-14 22:17:46< 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
2017-05-14 22:17:47< dwfreed> K_F: moderation should be soley on the basis of technical merit; arguably wltjr's posts add nothing but personal agenda
2017-05-14 22:18:05<@blueness> guys back on track please, we are discussing whether we want a moderated list
2017-05-14 22:18:08<@dilfridge> It's not so much about dissenting views as about offtopic ravings
2017-05-14 22:18:18< dwfreed> if it contributes nothing useful to the discussion, it gets moderated
2017-05-14 22:18:18<@K_F> blueness: no
2017-05-14 22:18:20<@dilfridge> and about doing something
2017-05-14 22:18:48<@WilliamH> dwfreed: My only concern is about the amount of work for someone...
2017-05-14 22:18:52<@K_F> dilfridge: to me that goes back to properly defining the scope of the mailing lists
2017-05-14 22:18:59<@WilliamH> dwfreed: moderation of the lists to me means like g-d-a
2017-05-14 22:19:05<@K_F> and a general S/N ratio discussion
2017-05-14 22:19:21<@WilliamH> dwfreed: so someone would have to approve all of the messages.
2017-05-14 22:19:22<@blueness> (i'll let the discussion go on a bit more but then i'd like to vote on this)
2017-05-14 22:19:39< dwfreed> WilliamH: I think a 'trust bit' implementation would work well
2017-05-14 22:20:06<@dilfridge> oh please let's decide a fundamental question first, not go straight into implementation details
2017-05-14 22:20:20< dwfreed> ^
2017-05-14 22:20:49< jmbsvicetto> leio: So you're looking at the userrel side of comrel?
2017-05-14 22:21:09<@K_F> as for the PR question, anyone reading the archives understands that this is dissenting views and not one of Gentoo
2017-05-14 22:21:19<@K_F> but is that sufficient for moderation of that view?
2017-05-14 22:22:19< 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
2017-05-14 22:22:40< dwfreed> K_F: I'm not sure that they necessarily do
2017-05-14 22:23:07< 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
2017-05-14 22:23:13<@K_F> my first response is, stop replying to troll-bait
2017-05-14 22:23:29<@dilfridge> jmbsvicetto: does not parse
2017-05-14 22:23:32< leio> jmbsvicetto: maybe; well, either, but in the devrel aspect we can boot it into the userrel aspect...
2017-05-14 22:24:01< dwfreed> K_F: see eg https://archives.gentoo.org/gentoo-project/message/52c3960d83d95b0b7afaf55404652197
2017-05-14 22:24:21< 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
2017-05-14 22:24:23<@dilfridge> K_F: I'm also not sure that people can differentiate
2017-05-14 22:24:38<@dilfridge> jmbsvicetto: yes, that's indeed bulshytt
2017-05-14 22:24:42< jmbsvicetto> leio: devrel never took part in issues involving users
2017-05-14 22:24:58<@K_F> dwfreed: yes, I've seen it..
2017-05-14 22:25:13< 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.
2017-05-14 22:25:40< jmbsvicetto> leio: yes, but this whole discussion is about a prior developer, thus a user
2017-05-14 22:25:54<@dilfridge> K_F: especially with wltjr blustering about "former developer, former trustee, ..." people do perceive him as someone "important"
2017-05-14 22:26:09<@blueness> guys can we bring this discussion to a conclusion please
2017-05-14 22:26:10<@blueness> are people ready to vote?
2017-05-14 22:26:11< 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
2017-05-14 22:26:23< NeddySeagoon> jmbsvicetto: List moderation ... for a single correspondent?
2017-05-14 22:26:39<@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
2017-05-14 22:26:50<@ulm> blueness: what was the exact motion again?
2017-05-14 22:27:00<@K_F> ulm: moderation of lists
2017-05-14 22:27:14<@blueness> okay proceeding with the vote:  do we want moderation of gentoo-dev and gentoo-project
2017-05-14 22:27:15<@dilfridge> ok let's write this up a bit more specific
2017-05-14 22:27:16 * blueness no
2017-05-14 22:27:29 * K_F no
2017-05-14 22:27:34 * dilfridge yes
2017-05-14 22:27:48<@dilfridge> (assuming for non @gentoo.org addresses)
2017-05-14 22:28:15<@blueness> WilliamH: jlec ulm rich0
2017-05-14 22:28:52 * ulm no
2017-05-14 22:29:19 * jlec no
2017-05-14 22:29:27<@blueness> rich0 WilliamH
2017-05-14 22:29:35<@dilfridge> rich0 isnt here anymore
2017-05-14 22:29:49 * WilliamH no only because  of manual overhead
2017-05-14 22:30:12<@blueness> okay this motion fails.
2017-05-14 22:30:30<@blueness> what i recommend is that the next time before bringing thsi forward again, there is a better plan
2017-05-14 22:30:38<@blueness> maybe some prediscussion
2017-05-14 22:30:59<@blueness> finally 6. Open Floor
2017-05-14 22:31:04<@dilfridge> well that kind of requires that people participate
2017-05-14 22:31:20<@blueness> dilfridge: maybe a discussion on gentoo-core?
2017-05-14 22:31:21<@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
2017-05-14 22:31:47<@K_F> dol-sen: i.e to get gkeys fully implemented et al
2017-05-14 22:32:51< dwfreed> portage generation and validation of MetaManifests is the biggest thing
2017-05-14 22:32:51<@blueness> okay if there's nothing more, meeting over
2017-05-14 22:33:05<@K_F> blueness: that is for open floor
2017-05-14 22:33:15<@blueness> sorry
2017-05-14 22:33:28< leio> what happens about sparc/ia64
2017-05-14 22:33:44<@dilfridge> what happens about ppc
2017-05-14 22:33:50 * WilliamH says move them to dev or exp
2017-05-14 22:34:00< Soap__> yes please
2017-05-14 22:34:07< Soap__> lets move sparc/ia64 to dev
2017-05-14 22:34:14< Soap__> ppc has received a formal complaint
2017-05-14 22:34:19< Soap__> so that is out of the question
2017-05-14 22:34:24<@K_F> leio: we seem to be dropping them from security supported architectures at least (sparc that is, ia64 has never been officially supported)
2017-05-14 22:34:31< Soap__> to date noone from ia64/sparc has replied
2017-05-14 22:35:09<@dilfridge> zlogene
2017-05-14 22:35:30<@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?
2017-05-14 22:35:34< Soap__> well, zlogene complained, but said himself he doesnt actually do anything for the archs
2017-05-14 22:35:43<@WilliamH> I need to bail, but count me as voting yes for both sparc and ia64 going to dev
2017-05-14 22:35:56< dwfreed> K_F: if it is, nobody's pointed it out to me
2017-05-14 22:36:18< Soap__> complaining about moving to dev is one thing
2017-05-14 22:36:25< Soap__> doing the actual work is another
2017-05-14 22:36:31<@blueness> guys, i have to run, dilfridge can you  send me the logs please
2017-05-14 22:36:35<@dilfridge> will do
2017-05-14 22:36:40<@K_F> dwfreed: it was part of last year's GSoC 
2017-05-14 22:36:41<@blueness> ty
2017-05-14 22:36:48< dwfreed> K_F: it didn't finish
2017-05-14 22:38:53<@dilfridge> ok so do we still have anything to discuss?
2017-05-14 22:39:17< Soap__> so no vote on ia64/sparc -> dev?
2017-05-14 22:39:37<@K_F> Soap__: if voting it should be brought up in the official agenda
2017-05-14 22:39:51<@dilfridge> Soap__: well, I personally recommend that you go ahead with the dekeywording plan
2017-05-14 22:40:04<@dilfridge> and if the result is too big, mask some more useflags
2017-05-14 22:40:24< Soap__> dilfridge: https://github.com/gentoo/gentoo/pull/4614
2017-05-14 22:41:05< dol-sen> K_F, I'm back for a few
2017-05-14 22:41:09<@dilfridge> I know that, but it doesnt look finished
2017-05-14 22:41:13<@dilfridge> :P
2017-05-14 22:41:19<@K_F> dol-sen: is there anythign we can do to move things along?
2017-05-14 22:41:19< Soap__> dilfridge: still
2017-05-14 22:41:26< Soap__> xmw seems to be against
2017-05-14 22:41:32< Soap__> and at some point I'd like vote on it
2017-05-14 22:41:44< leio> that'd be ppc then, afaiu
2017-05-14 22:41:44< Soap__> otherwise I will proceed unilaterally for some CATs
2017-05-14 22:41:46<@K_F> dol-sen: what is needed in terms of contributions to get it done?
2017-05-14 22:41:50< dol-sen> yeah, poke Robin to get the key cards, new infra keys established
2017-05-14 22:42:18< dol-sen> we also need more testing bug-fixes for gkeys-gpg
2017-05-14 22:42:21<@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
2017-05-14 22:42:36< Soap__> dilfridge: we can table it for the next time
2017-05-14 22:42:49<@dilfridge> ok anything else
2017-05-14 22:42:59< dol-sen> and most importantly we need permanent home and setup to keep the gentoo-devs seeds up to date
2017-05-14 22:43:00<@K_F> dol-sen: any testing procedure we can recommend?
2017-05-14 22:43:23<@K_F> dol-sen: right, which is currently being done on vulture and distributed on api.g.o
2017-05-14 22:43:46< dol-sen> yeah, set .git/config to point to the gkeys-gpg command and test git log --show-signature
2017-05-14 22:43:52<@dilfridge> K_F: is this technical discussion necessary now?
2017-05-14 22:44:03< dol-sen> K_F, yes
2017-05-14 22:44:38<@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
2017-05-14 22:45:11<@dilfridge> well, while I agree that Gentoo is a bit stone-age there, I'm not sure what the council can contribute
2017-05-14 22:45:15<@K_F> but indeed, we can continue it on MLs etc, but we need to get it in place
2017-05-14 22:45:22< 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
2017-05-14 22:45:38< dol-sen> and set the mast to run it on a timer
2017-05-14 22:45:55< dol-sen> then it'd have a web interface of the runs, to see for errors, etc.
2017-05-14 22:46:00 * dilfridge has this distinct feeling that an overcomplicated solution is in the works
2017-05-14 22:46:45<@dilfridge> you know, we could, like, go from stone age to iron first, and dont immediately need superconductors
2017-05-14 22:47:02< 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
2017-05-14 22:47:26< dol-sen> and I don't always have time for that
2017-05-14 22:47:44<@dilfridge> anyway, I think we can close the council meeting now, before attendance and attention even falls further
2017-05-14 22:47:44<@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
2017-05-14 22:47:56<@K_F> dilfridge: wfm
2017-05-14 22:48:00<@dilfridge> 3
2017-05-14 22:48:03<@dilfridge> 2
2017-05-14 22:48:04< dol-sen> besides buildbot is not that difficult
2017-05-14 22:48:06<@dilfridge> 1
2017-05-14 22:48:10<@dilfridge> -bang-
2017-05-14 22:48:14<@dilfridge> meeting closed
2017-05-14 22:48:47<@ulm> blueness wanted an --- end --- tag
2017-05-14 22:48:58<@K_F> :)
2017-05-14 22:49:00< dol-sen> K_F, it would also be nice is some people stepped forward to help finish off the gkeys client features and debugging
2017-05-14 22:49:26<@K_F> dol-sen: any TODO-list of what people can contribute to?
2017-05-14 22:49:29<@dilfridge> ulm: I rather go out with a bang
2017-05-14 22:50:09< dol-sen> K_F, bugs, test the code, see what people bitch about...
2017-05-14 22:50:10<@K_F> dol-sen: maybe a mailing list post and updated b.g.o tracker?
2017-05-14 22:50:27< dol-sen> yeah, it all needs work
2017-05-14 22:50:35<@K_F> dol-sen: but in particular the rsync master signing and validation code testing
2017-05-14 22:50:58< dol-sen> and with my work schedule and real life, I don't have that much time to work on things these days
2017-05-14 22:51:10<@K_F> all needing work is about as useful as nothing needing, we should try to make it specific
2017-05-14 22:51:39< dol-sen> yes, there is a little more work to do on the master manifest code, but not that much
2017-05-14 22:52:15<@K_F> that is my recollection, could we enable it by a configuration switch and start reporting issues ?
2017-05-14 22:52:29<@K_F> (which naturally requires things to be signed in rsync master)
2017-05-14 22:52:41< dol-sen> if there are other areas making progress, I know Zac and I could make sure that is finished and released
2017-05-14 22:56:22<@K_F> dol-sen: we need to get it in place anyhow
2017-05-14 22:56:51< dol-sen> gotta go, back later
2017-05-14 22:57:20<@K_F> so, anyone available to help, lets continue in #gentoo-keys
2017-05-14 22:59:32< leio> lalala, https://bugs.gentoo.org/show_bug.cgi?id=618420#c1
2017-05-14 22:59:33< leio> much fun
2017-05-14 23:00:02< Soap__> leio: that is not considered abuse because its not in devmanual
2017-05-14 23:00:22< Soap__> I think its great that jer can randomly add his '=' to package lists
2017-05-14 23:00:35< Soap__> we don't want to censor free expression within the package list
2017-05-14 23:01:06< leio> oh, refresh that now
2017-05-14 23:01:28<@ulm> can't bugzilla be configured to reject certain characters in a field?
2017-05-14 23:01:38<@ulm> like <>=
2017-05-14 23:01:56< leio> are you volunteering to do this work because one person can't get a clue?
2017-05-14 23:02:40< leio> I don't care about =, it's valid, I care about it being edited without authorization, and I'm not going to want to re-validate the full list for lack of easter egg changes in it
2017-05-14 23:02:49<@ulm> leio: I had worse comments in my bugs :)
2017-05-14 23:03:20< Soap__> so now having had worse comments is the bar?
2017-05-14 23:03:24<@ulm> https://bugs.gentoo.org/show_bug.cgi?id=617340#c2
2017-05-14 23:03:33 * WilliamH is here for a sec, what did we decide wrt ia64 and sparc?
2017-05-14 23:04:26< Soap__> WilliamH: deferred
2017-05-14 23:04:27<@ulm> leio: but I agree, the bug spam plus having to verify the list is what is annoying
2017-05-14 23:04:27<@K_F> WilliamH: no decisions made 
2017-05-14 23:06:01< leio> my point is that it was always maintainer jurisdiction
2017-05-14 23:06:29< leio> it's just now easier for some random stubborn dude to edit it, while it was an obvious yelling if some random non-maintainer dude attached a new package list attachment
2017-05-14 23:06:31<@K_F> leio: I'm still waiting for proper references of that
2017-05-14 23:06:51< leio> try reading my mail
2017-05-14 23:07:38<@K_F> leio: got a reference for any email in particular?
2017-05-14 23:07:40< leio> arch teams just had to check manually who was doing the attaching or list in comments and ignore non-maintainer stuff
2017-05-14 23:08:05< leio> now this is automated to speed things up as a side result of the WG you are leading or something
2017-05-14 23:08:17< leio> but this being changed by others is messing with that workflow
2017-05-14 23:08:30<@ulm> right, formerly such package lists were posted in a comment, where they were immutable
2017-05-14 23:09:20<@K_F> ulm: immutable in comment, but not restricted to maintainers requesting it
2017-05-14 23:09:37< leio> yes, it was restricted to maintainers from the ack
2017-05-14 23:09:45< leio> with the new workflow that ack happens when arches are CCed
2017-05-14 23:09:45<@dilfridge> usually cc'ing arches was restricted to maintainers
2017-05-14 23:09:50< leio> AFTER that package list is off limits to non-maintainer
2017-05-14 23:10:03<@K_F> dilfridge: security project is a good example of it not being so
2017-05-14 23:10:31<@dilfridge> security project is the weird unsanctioned exception
2017-05-14 23:10:32< leio> Michael Jones replied you, and I replied him, including replies to you as well.
2017-05-14 23:10:59< leio> security project doesn't touch package list either
2017-05-14 23:11:03< leio> and if they do, not really after arches are CCed
2017-05-14 23:11:08<@K_F> dilfridge: but given security project claims no special privileges, its not different from any other project/dev
2017-05-14 23:11:51< leio> I don't mind proper commented tweaks to package list prior to CC, I think that's fine; after CC of arches is what I take issue with
2017-05-14 23:12:29< Soap__> like me adding libpeas :P
2017-05-14 23:12:50< leio> yes, I specifically ask to propose things to a monthly stabilization list, and I look it all over before I CC arches
2017-05-14 23:12:58< leio> and then some others think it's fine to keep editing it for their whims.
2017-05-14 23:13:08< Soap__> I mean
2017-05-14 23:13:22< Soap__> how bad does your tooling have to be to not be able to do that on your side?
2017-05-14 23:13:23< leio> I mean, I don't want to single out anybody
2017-05-14 23:13:29< leio> but a single person is the only person ever doing that on my bugs
2017-05-14 23:13:44<@K_F> leio: all I'm asking is, point me at some authorative regulation, GLEP, QA, whatever, that makes it so if asking about reactions
2017-05-14 23:13:57<@K_F> council decision..
2017-05-14 23:14:29< leio> I believe you are the lead of the working group whose member came up with it and documented the whole process, so I don't think I need to go digging anything myself.
2017-05-14 23:14:57<@dilfridge> (rolling eyes) do we really need to have a written policy for everything?
2017-05-14 23:15:00<@K_F> leio: by all means, but we haven't presented that for council for ratification , so that isn't authorative
2017-05-14 23:15:19< leio> the alternative is that ago stops doing work based on it and every single arch stalls.
2017-05-14 23:15:25< dwfreed> what dilfridge said
2017-05-14 23:15:40< Soap__> K_F: so yes
2017-05-14 23:15:44< Soap__> all the package fields etc
2017-05-14 23:15:51< Soap__> are not part of the official workflow
2017-05-14 23:16:02< Soap__> we've been doing stuff for months without it officially being sanctioned
2017-05-14 23:16:08< Soap__> nice
2017-05-14 23:16:30<@dilfridge> maybe we should stop that for a while, until it's sanctioned
2017-05-14 23:16:34< Soap__> yes
2017-05-14 23:16:53<@K_F> Soap__: the change in workflow itself is nice, but if we want to sanction users based on it it is a different matter
2017-05-14 23:16:53< dwfreed> can't have unsanctioned progress going on
2017-05-14 23:16:57< Soap__> also, please vote on it only after the new council came in
2017-05-14 23:17:13< Soap__> K_F: nah, we cant require people to use it if its not been voted on
2017-05-14 23:17:17< Soap__> you know, procedures
2017-05-14 23:17:41< leio> ago specifically doesn't do keyword requests due to that stuff being not fully agreed; there are more open things about keywording
2017-05-14 23:18:26< Soap__> the fact that only amd64/x86/alpha and maybe arm are not dead
2017-05-14 23:20:02<@K_F> leio: fwiw, I haven't seen any patches to propose the changes in the wg recommendations to the council
2017-05-14 23:20:14<@ulm> Soap__: but nios and riscv!
2017-05-14 23:20:46<@K_F> (but yes, I need to revive those discussions)
2017-05-14 23:21:18< Soap__> ulm: how dare you forget sh!
2017-05-14 23:21:35<@K_F> preferably those patches includes a clear definition of how the field should be made out
2017-05-14 23:21:45< leio> I'm sorry, what patches?
2017-05-14 23:22:01<@K_F> leio: the WG report
2017-05-14 23:22:56<@K_F> https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf | https://git.sumptuouscapital.com/?p=gentoo/wg-stable.git;a=summary
2017-05-14 23:23:14< leio> I don't do latex, nor did I join that WG
2017-05-14 23:23:16<@K_F> (kensington has write access to it)
2017-05-14 23:23:44< leio> kensington is demotivated by happenings like what I'm bitching about.
2017-05-14 23:24:45< Soap__> I second those emotions
2017-05-14 23:24:46<@K_F> the field is not defined anywhere as it stands
2017-05-14 23:24:49< leio> This is a common theme in Gentoo right now, people could be doing great stuff, but something ends up demotivating them, usually communication related, instead of being empowered
2017-05-14 23:25:18< leio> https://wiki.gentoo.org/wiki/Stable_request
2017-05-14 23:25:22< Soap__> leio: like waiting for ppc KEYWORDREQs?
2017-05-14 23:25:34<@K_F> wg-stable is a way to do that in this case, a path of least resistance to proposing changes to stable workflow
2017-05-14 23:26:13< leio> like a wise man said, do we need a written policy for everything?
2017-05-14 23:26:25< leio> this wiki page went through gentoo-dev and was generally agreed upon
2017-05-14 23:26:26< Soap__> apparently
2017-05-14 23:27:46< Soap__> its so blatantly obvious that the package field is maintainer metadata
2017-05-14 23:27:47< Soap__> like
2017-05-14 23:27:49< leio> I'm sorry if your WG doesn't keep up
2017-05-14 23:28:05<@K_F> leio: that wiki page has abnormalities, "a fully qualified package per line" would correspond to cat/pkg, not including version specification
2017-05-14 23:28:57< leio> ok, so we need to define to you what a fully qualified package per line is, got it
2017-05-14 23:29:22< leio> refer to the example meanwhile
2017-05-14 23:29:39<@K_F> it also mention still supported =....
2017-05-14 23:30:02<@K_F> i.e a change from non-"=" to "=" doesn't change the underlying meaning, and is still an acceptable format
2017-05-14 23:30:07<@K_F> i.e nothing to sanction for change of
2017-05-14 23:30:15< leio> it is maintainer metadata after CC, it MUST NOT be touched by non-maintainers
2017-05-14 23:30:19< leio> it's so obvious and common sense
2017-05-14 23:30:22<@ulm> K_F: that still doesn't justify changing it from preferred syntax to legacy syntax
2017-05-14 23:30:39< Soap__> ulm: in other news
2017-05-14 23:30:44< Soap__> why doesnt that work for portage?
2017-05-14 23:30:51< Soap__> emerge gcc-6.3.0
2017-05-14 23:31:10<@K_F> further on it states "If a large number of atoms are being stabilized at once, it might be preferred to use an attachment to list the atoms instead of the field"
2017-05-14 23:31:13< leio> like everybody who maintains more than 20 packages or is on an active architecture team knows that contract between maintainers and arch teams
2017-05-14 23:31:22<@K_F> atom of which would require the = syntax
2017-05-14 23:31:27< dwfreed> Soap__: because portage expects dependency specifications
2017-05-14 23:31:46<@ulm> Soap__: indeed, after we removed the ambiguity on PN I had expected portage to get more liberal in what it accepts
2017-05-14 23:32:19< Soap__> ulm: also, portage still talks about atoms
2017-05-14 23:32:23<@ulm> K_F: atom isn't a well defined term
2017-05-14 23:32:25< Soap__> time to change that?
2017-05-14 23:32:42<@ulm> shrug
2017-05-14 23:32:46<@K_F> ulm: I don't disagree with that in PMS sense, but from portage point of view I'd say its not too ambiguous
2017-05-14 23:32:57<@K_F> ulm: the point is, that wiki page mixes terms like a drunken sailor
2017-05-14 23:33:00< leio> the people who actually work on this stablebot workflow consider stabilisation list attachments deprecated and haven't paid attention to the wording there I suppose.
2017-05-14 23:33:15<@K_F> and its anyways not authorative in any case, so certainly can't be used as a basis for sanctions
2017-05-14 23:33:48< leio> We don't need a council decision for every bloody tiny common sense thig
2017-05-14 23:33:49< leio> thing
2017-05-14 23:33:50< leio> sigh
2017-05-14 23:34:05< leio> stop the nonsensic bureacracy
2017-05-14 23:34:13< Soap__> K_F: changing fields to fit your OCD geenrating tons of bug spam I consider abuse of the system
2017-05-14 23:34:31<@K_F> Soap__: not as long as it is approved format
2017-05-14 23:34:32< Soap__> it adds 0 value
2017-05-14 23:34:37< leio> this workflow has been discussed, agreed upon and everyone uses it
2017-05-14 23:34:40< Soap__> K_F: no, because it gains 0
2017-05-14 23:34:44< Soap__> and produces bugspam
2017-05-14 23:34:48< Soap__> how hard is it?
2017-05-14 23:34:56< leio> if you don't use it, you actually will never get your package stablized
2017-05-14 23:39:31-!- mode/#gentoo-council [+o blueness_] by ChanServ
2017-05-14 23:40:14-!- mode/#gentoo-council [+o ulm_] by ChanServ
2017-05-14 23:41:52-!- mode/#gentoo-council [+o WilliamH_] by ChanServ
2017-05-14 23:42:59< dwfreed> this conversation is an example of a not-insignificant reason contributing to my decision to not continue pursuing recruitment