|author||Ulrich Müller <email@example.com>||2019-10-14 00:15:31 +0200|
|committer||Ulrich Müller <firstname.lastname@example.org>||2019-10-14 00:15:31 +0200|
|parent||council/meeting-logs: add 20190908 logs summary (diff)|
Log for 20191013 meeting.
License: CC-PDM-1.0 (raw IRC log, not copyrightable) Signed-off-by: Ulrich Müller <email@example.com>
2 files changed, 402 insertions, 0 deletions
diff --git a/meeting-logs/20191013.txt b/meeting-logs/20191013.txt
new file mode 100644
@@ -0,0 +1,391 @@
+<@ulm> roll call
+<@ulm> !proj council
+<+willikins> (firstname.lastname@example.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:
+<+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
+<@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
+<@ulm> does anyone have his phone number? [21:04]
+<@WilliamH> I don't unfortunately.
+<@ulm> well, let's proceed [21:05]
+<@ulm> allow pkgcheck as repoman replacement
+<@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)
+<+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.
+* mgorny votes for not voting
+<@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
+<@ulm> let's move on
+<@ulm> valid forms of activity for recruitment/retirement
+<@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
+<+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
+<@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
+<@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> 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
+<+mgorny> NeddySeagoon: he gets the right to vote on the council, for example
+<+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
+<+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
+<+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;
+<@ulm> also a tracker
+<@ulm> AFAICS, the only remaining blocker is renaming of the snapshot tarball
+* 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?
+<@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
+<@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:
+<@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.
+<[Arfrever]> EAPI=8 could use colon separator, if desired.
+<@ulm> mgorny: can your script be changed to flag only newly added flags?
+<+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
+<@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
+<@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
+<+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;
+<@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.
+<@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.
+<@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
diff --git a/meeting-logs/20191013.txt.asc b/meeting-logs/20191013.txt.asc
new file mode 100644
@@ -0,0 +1,11 @@
+-----BEGIN PGP SIGNATURE-----
+-----END PGP SIGNATURE-----