<@ulm> roll call <@ulm> !proj council <+willikins> (council@gentoo.org) dilfridge, gyakovlev, patrick, slyfox, ulm, whissi, williamh * slyfox here * WilliamH here <@Whissi> Of course, DSL outage :/ * mgorny here for dilfridge * Whissi here * DrEeevil here <@slyfox> gyakovlev: ^ [21:01] <@ulm> let's give him a few minutes <@ulm> meanwhile, here's the agenda: https://archives.gentoo.org/gentoo-dev-announce/message/1da4fde91bd8de044551dc3126143a4f <+mgorny> ftr, there are some items of me on the agenda, so i'll be talkign about them as myself but voting as instructed by dilfridge [21:03] <@ulm> !seen gyakovlev <+willikins> ulm: gyakovlev was last seen 4 days, 21 hours, 29 minutes and 6 seconds ago, saying "so using -l1 does not trigger it." in #gentoo-dev <@ulm> does anyone have his phone number? [21:04] <@WilliamH> I don't unfortunately. <@Whissi> No. <@ulm> well, let's proceed [21:05] <@ulm> allow pkgcheck as repoman replacement <@ulm> https://archives.gentoo.org/gentoo-project/message/915d843e638656fc037dc21aa0e7243f <@ulm> mgorny: do you want to elaborate on this? <@Whissi> Could someone help me to understand why using pkgcheck would require council approval? I was unable to find a requirement for using repoman at all (only recommendation, but no YOU JUST USE). So people can do whatever they want. We don't care about the tools or workflow each developer uses to avoid bad commits. Only the result is important. [21:06] <+mgorny> still, it's a wide understanding that you're expected to repoman <+mgorny> if the only outcome of this is saying 'we don't care, do whatever', then sure, it works for me <@slyfox> i'd say it's QAs territory to provide policies and tools that enforce them. besides pkgcheck does not known how to generate commits (at least last ime i was not able to coomit with it) [21:07] <+mgorny> slyfox: that's by design. pkgcore doesn't follow in the land of creeping featurism <@WilliamH> I think it is more qa terratory as well. <+mgorny> committing with repoman was a good thing when you needed lots of magic to get around cvs * gyakovlev here, sorry <@slyfox> Then "allow pkgcheck as repoman replacement" is infeasible and that's the end of discussion. <@ulm> maybe we should also remember that pkgcore used to be late in adopting EAPIs [21:08] <+mgorny> hey, i'm not talking of *replacing* repoman <@ulm> AFAICS it supports EAPI 7 since less than 2 months <@slyfox> that's what agenda item states <+mgorny> just making sure people won't be yelled at for not having repoman note in commit messages <@Whissi> You will only get problems when you commit shit. Then you have to answer why you don't use known tools which would catch such avoidable errors. [21:09] <@ulm> mgorny: inevitably, they'll be yelled at if they break the tree and repoman would have detected it ;) <@ulm> but yeah, I think we should delegate the issue to the QA team [21:10] <+mgorny> ok, so let's move on <@slyfox> any formal vote or everyone on the same page? <@ulm> everyone o.k. with delegating it? if not, please speak up now <@WilliamH> I don't think we need a formal vote. <@slyfox> ACK * mgorny votes for not voting <@gyakovlev> ^ <@ulm> gyakovlev: welcome :) <@Whissi> ACK [21:11] <@ulm> I don't see any objections <@DrEeevil> let QA figure it out, and if our vote is required later we can vote <@ulm> let's move on <@ulm> valid forms of activity for recruitment/retirement <@ulm> https://archives.gentoo.org/gentoo-project/message/6bfdb844b9a9abfaf8ae20c386308ba2 <@ulm> another mgorny item :/ <@Whissi> Is anyone except mgorny aware about any complaints regarding recruiters decision? Or let me rephrase: Recruiter might have rejected someone but I am not aware that anyone tried to appeal that decision. So I am not really sure what mgorny expect us to do... we (council) don't dictate rules. It's the community which defined rules (and for example community is currently working on clear undertaker project rules). <@Whissi> If there's a specific appeal... fine. But at the moment this item doesn't look actionable for me and should be skipped. <+mgorny> i'd like to get a clarification whether proxied maintainers should be allowed to be developers [21:12] <@WilliamH> Wouldn't the recruiters make that decision? <@WilliamH> mgorny: ^^ [21:13] <+mgorny> recently council voted on override of undertaker decision <@slyfox> i guess the current state is if they pass quizzies that would make sense <+mgorny> which effectively ends up in conflict with what appears to be recruiter policy <@WilliamH> mgorny: that was that one decision and there were circumstances around it. <@ulm> we have discussed quizzes in the july meeting <@ulm> which is related to this [21:14] <+mgorny> WilliamH: is that your justification for setting unfair rules to different individuals? <@ulm> Amynka and zlogene were supposed to raise this on mailing lists <@Whissi> I don't see a reason why someone from proxy-maint shouldn't become developer. I don't see the point if you don't do quizzes and don't get commit bits, but sure... we allow for that. <@WilliamH> mgorny: what ulm said, but it never happened. [21:15] <@ulm> IMHO it's for recruiters to work out a proposal if they think that rules should be changed <@ulm> and get consensus on mailing lists [21:16] <+mgorny> but what are the current rules? <@ulm> it's not something to be decided ad-hoc by the council <@Whissi> We allow for developers without commit access. <@ulm> IIUC current rules require passing the quizzes <@Whissi> Former staffer quizzes, yes <+mgorny> so the proxied maintainer in question should be allowed to join after filling the shorter developer quiz? [21:17] <@ulm> Whissi: yes <@WilliamH> what ulm said, you currently have to pass the quizzes <@WilliamH> and interviews with recruiters <@ulm> mgorny: it's a strange construction in any case, normally developers doing ebuild work should have commit access [21:18] <+zlogene> mgorny: shortest developer quiz does not provide any base to join, unless proxied maintainer is busy in areas like security/infra <@WilliamH> until the recruiters bring it up on the ml and change things. <@ulm> being proxied causes additional work for other devs <@slyfox> recruiters@ should be best fit to document current rules <+mgorny> ulm: now you repeat my arguments from before <@WilliamH> I don't think anyone ever came up with a fast track for a proxy maintainer to become a dev. [21:19] <@WilliamH> You still have to go through the recruitment process with a mentor etc. <@Whissi> The main idea still is: You start contributing, of course without commit access... and once you will turn into full developer with commit access. That should be the goal for most people. <+mgorny> yes but there shouldn't be a need to fill out the long ebuild quiz or be questioned in detail wrt ebuild writing <+zlogene> Whissi: nah, there were an attempt to appeal in early '17, but the rule of thumb was/is that council may express the opinion, but not really to overrule recruiters <@Whissi> proxy-maint is just another form of contributing. Like before... where we only had bugzilla. [21:20] <@WilliamH> Personally mgorny I agree. once yu are a proxy maintainer, I would say if two devs say you can become a dev you can. <@WilliamH> But, that's not the current process. [21:21] <@ulm> yeah, if recruiters want something different, then recruiters should work something out [21:22] <@ulm> we cannot come up with a new procedure during a council meeting <@gyakovlev> mgorny: you mentioned how netbsd vouchin system works, is it similar to what WilliamH just said? <@WilliamH> I would say the only thing we can do is disband recruiters and put new people there. [21:23] <+mgorny> gyakovlev: not really, it's just sending a global RFC <+mgorny> if nobody replies (negatively), then the person is accepted <+mgorny> nobody needs to reply <@WilliamH> I'm not saying we should disband recruiters. [21:24] <@WilliamH> Just that's all we can do as the council, we shouldn't try to establish the recruiting process in this meeting. <+NeddySeagoon> Thats for recruiters [21:25] * mgorny still doesn't understand why Council believes recruiters have full autonomy over who gets recruited, yet claims authority over retiring developers <@ulm> mgorny: you're proxying, so you could come up with a motion [21:26] <+mgorny> i'm quite concerned that we apparently have some rules that apply to some people but not to others <@ulm> *sigh* <@ulm> mgorny: the decision in the 2019-05-12 meeting (which you refer to in your agenda item) was specific to one single dev only, with very unique circumstances [21:27] <+mgorny> well, the thing i'd like to see is a formal confirmation <@ulm> it was never meant to set general rules <+mgorny> either a proxied maintainer can become a dev with dev quiz, and then recruiters should respect that <@Whissi> I still don't get the motion you are asking for. <@WilliamH> mgorny: ulm is correct about that. we didn't set general rules with that decision. <+mgorny> even if we can't force recruiters to respect the decision, a decision can be made <+NeddySeagoon> mgorny: What are the advantages of having a PM become a staffer? <+mgorny> NeddySeagoon: he gets the right to vote on the council, for example [21:28] <+mgorny> as gratification for his work for gentoo so far <@WilliamH> mgorny: There's nothing for us to decide at this level. <@Whissi> mgorny: Of course a proxied maintainer can become dev with dev quizzes. Proxy-maint is _one_ way to demonstrate you contribute... now find a mentor and start... recruiter won't reject that. Did they? <+mgorny> Whissi: yes, they did <+mgorny> and demanded full ebuild quiz instead <@Whissi> When you want commit access... sure. [21:29] <@WilliamH> mgorny: they can do that because that's the current process. <+mgorny> Whissi: he doesn't need full commit access right now <@ulm> mgorny: but is doing ebuild work? <+mgorny> ulm: yes, with reviews from a proxy [21:30] <@WilliamH> mgorny: ok, what exactly does he need? <+zlogene> mgorny: proxied maintainer *can* become a developer with a.) the developer quiz if he/she is active in the areas like infra or security (which do not require you to get +w, so g-p-m is irrelevant as is) b.) the ebuild maintainer quiz (that is where ebuild contributions become essential part as you are going to attain +w) <+mgorny> WilliamH: i'm not saying he needs anything. i'm saying he *deserves* dev status for his level of contribution so far [21:31] <+mgorny> even if he doesn't have time or motivation to go through long ebuild quiz <+mgorny> provided he's got a willing mentor and developers willing to proxy for him <@ulm> which shouldn't take longer than a few hours <+mgorny> ulm: depends on personality [21:32] <@ulm> anyway, I don't see anybody coming up with a motion for this item <+mgorny> ok, let's put this different [21:33] <@ulm> I'd suggest that we move on <+mgorny> let's say this contributor decides not to use his real name <+mgorny> would it be suddenly feasible for him to join without commit access? <@ulm> please, not the real name discussion again <@Whissi> ulm: Let's move on. * WilliamH sighs <@slyfox> +1, set's move on <@ulm> we don't want devs doing ebuild work anonymously <+mgorny> yet you approved that <+mgorny> now you avoid the consequences [21:34] <@Whissi> You really don't understand what happend in the meeting in question. :/ <@ulm> mgorny: in one special case which was grandfathered <@ulm> moving on <@ulm> open bugs with council participation <@ulm> bug 637328 <+willikins> ulm: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security <@ulm> no updates on this one, I suppose? <@Whissi> :] [21:35] <@ulm> bug 642072 <+willikins> ulm: https://bugs.gentoo.org/642072 "[Tracker] Copyright policy"; Gentoo Council, unspecified; IN_P; mgorny:council <@ulm> that's just a tracker, no action for now <@ulm> bug 662982 <+willikins> ulm: https://bugs.gentoo.org/662982 "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage <@ulm> also a tracker <@ulm> AFAICS, the only remaining blocker is renaming of the snapshot tarball [21:36] * ulm wonders what is so difficult about that <@ulm> bug 695172 <+willikins> ulm: https://bugs.gentoo.org/695172 "Please clarify QA policy regarding USE flags with underscores"; Gentoo Council, unspecified; CONF; arfrever.fta:council <+mgorny> ulm: besides the snapshot script being horrible? [21:37] <+mgorny> afair my patch isn't liked because it creates the tarball twice * [Arfrever] is here in case there are any questions about my appeal (in #695172). [21:38] <@ulm> mgorny: anyway, we won't solve it in this meeting <@ulm> [Arfrever]: AFAICS, there's no decision to appeal to [21:39] <[Arfrever]> ulm: All members of PMS project have written their answers in comments #1 and #2. <@Whissi> The motion is to stop removing USE flags with underscores, not? [21:40] <@ulm> maybe you can *escalate* to the council <[Arfrever]> ulm: I consider these comments as negative decision of PMS project and I appeal this decision. <@ulm> Whissi: not entirely sure if the motion would be about PMS wording or something else <@ulm> as I said in comment 7 of the bug, PMS wording is "Underscores should be considered reserved for USE_EXPAND" [21:42] <@ulm> which is not a hard requirement <@Whissi> ulm: People don't understand why there was suddenly a movement to mass change ebuilds to change USE flags containing underscores. There's a user impact because user have to adapt to new names. No auto change like pkg move. From reading PMS I also don't understand why there was such a movement. Underscores should be fine. <[Arfrever]> The possible motion would be to explicitly allow underscores, and only make policy to avoid only these USE flags which really can confuse users. <@ulm> it's mostly about namespaces <@ulm> [Arfrever]: the spec listing many special cases as these in comment #20 would be very inappropriate [21:43] <[Arfrever]> I want problematic sentence droped from PMS, because this sentence was mentioned in pkgcheck when controversial "QA" check was added. [21:44] <@ulm> that sentence was changed from "must" to "should" in 2007 <@Whissi> ACK. <@WilliamH> ulm: So not using underscores is not a hard requirement? <@ulm> and I think the wording is completely fine <@ulm> WilliamH: it should be avoided <+mgorny> this really sounds like someone trying to workaround the actual problem via PMS changes [21:45] <+mgorny> and getting around the right people in the process <[Arfrever]> pkgcheck commit: https://github.com/pkgcore/pkgcheck/commit/385eb7df88667453ac351f63e21240eaed35f660 <@ulm> as I see it, underscores shouldn't be used in any new USE flags [21:46] <@ulm> but there isn't much pressure to change existing ones <@ulm> because technically they work [21:47] <@ulm> and cleaning up namespaces isn't an urgent matter <@Whissi> I agree on this interpretation. <@slyfox> +1 <[Arfrever]> EAPI=8 could use colon separator, if desired. <@ulm> mgorny: can your script be changed to flag only newly added flags? [21:48] <+mgorny> ulm: i don't see how that would be technically feasible <@ulm> whitelist for all currently existing ones? <+mgorny> do you expect pkgcheck to bundle special exception data? [21:49] <@WilliamH> ulm: that would be difficult probably. <@ulm> *shrug* just don't mark it in red or bright yellow then, but keep it in the list? <+mgorny> that how's it's done right now [21:50] <@ulm> so where's the problem then? <+mgorny> however, if majority of them are gone and only [Arfrever]'s are left... <@WilliamH> Then the bugs you fild should be closed as wontfix or invalid? <+mgorny> i'd rather not see us applying special rules to one person <[Arfrever]> I disagree with trying to disallow underscores in future USE flags, in cases when underscores are good choice in given situation. [21:51] <@WilliamH> mgorny: no one said anything about special rules for one person. <@Whissi> Erm. Let me say it very clearly: It was very hostile from QA people to mass change hundreds of packages and force users to change for no reason. <@Whissi> And now saying, "Only one person's packages are left... so why should we still care" is... interesting. <+mgorny> what qa people? nobody forced anyone <@WilliamH> mgorny: what he is talking about is your mass-filing of bugs forcing people to change use flags. <+mgorny> i filed pkgcheck reports, people had the choice of doing it or not [21:52] <+mgorny> some people discussed it with me <+mgorny> apparently a fair number of people agreed to go for hyphens <@DrEeevil> so now that it's mostly done I'd strongly suggest finishing it <@DrEeevil> half-migrations are suck <@Whissi> lol - the PR and comments from you weren't like "Hey, I only propose that change. If you don't like... feel free to ignore." <+mgorny> Whissi: when i say people must do something, they tend to close it WONTFIX [21:53] <@WilliamH> mgorny: huh? [21:54] <+mgorny> i suppose that sentence didn't make much sense, nevermind it <+mgorny> it's too late to try to explain what i meant <@Whissi> DrEeevil also make a valid point. <@ulm> let me try to come up with a motion <@Whissi> *made [21:55] <@ulm> "Underscores should be considered reserved for USE_EXPAND. They shouldn't be used in any new 'normal' USE flags. Existing flags with underscores are technically valid; phasing them out has low priority." * slyfox votes yes <@ulm> any improvements to this wording? :) [21:56] <+mgorny> ulm: please make it mustn't <[Arfrever]> ulm: Why have you ignored idea of another separator for USE_EXPAND in future EAPI, and always allowing underscores? <@DrEeevil> [Arfrever]: future eapi is future problem <@DrEeevil> we're discussing now problem <+mgorny> [Arfrever]: you're breaking backwards compatibility <@WilliamH> ulm: what about [Arfrever] 's point? <@ulm> "Underscores should be considered reserved for USE_EXPAND. They must not be used in any new 'normal' USE flags. Existing flags are technically valid; phasing them out has low priority." <@ulm> please vote ^^ * slyfox votes yes [21:57] * ulm yes * DrEeevil abstain / rephrase <@ulm> [Arfrever]: colon as separator can be discussed later * gyakovlev yes [21:58] * Whissi abstain * WilliamH abstain <+mgorny> hmm, i guess that counts as 'do as you see fit' in my notes * mgorny yes <@ulm> accepted with 4 yes votes and 3 abstentions [21:59] <@ulm> bug 696882 <+willikins> https://bugs.gentoo.org/696882 "Register /EFI/Gentoo namespace in UEFI Subdirectory Registry"; Gentoo Council, unspecified; CONF; ulm:council <@Whissi> I stil don't understand why this change is necessary. It's either a problem, in this case we must migrate everything away from using underscores... or not. <@Whissi> *still <@ulm> Whissi: let's simply not add more flags with an underscore [22:00] <@ulm> no council action for that EFI bug either, I suppose <@WilliamH> Didn't someone contact the appropriate people for this bug? <@Whissi> Mr. President. <@ulm> WilliamH: antarus has sent another mail to the chairman [22:01] <@Whissi> But the person is on vacation. <@ulm> exactly <@WilliamH> ulm: ah ok. <@ulm> it's not an urgent matter, I guess nobody else would claim the gentoo name there <@ulm> open floor <@ulm> anyone? [22:02] * Whissi has nothing * ulm bangs the gavel [22:03] <@ulm> meeting closed