path: root/meeting-logs/20191013.txt

<@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