LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jani Nikula <firstname.lastname@example.org>
To: Greg KH <email@example.com>
Cc: "Theodore Y. Ts'o" <firstname.lastname@example.org>, "Bird\,
Subject: Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter
Date: Fri, 13 Mar 2020 12:30:20 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
On Fri, 13 Mar 2020, Greg KH <firstname.lastname@example.org> wrote:
> On Fri, Mar 13, 2020 at 10:58:00AM +0200, Jani Nikula wrote:
>> On Thu, 12 Mar 2020, "Theodore Y. Ts'o" <email@example.com> wrote:
>> > So that means we need to be smart about how we pick the criteria.
>> > Using a kernel.org account might be a good approach, since it would be
>> > a lot harder for a huge number of sock puppet accounts to meet that
>> > criteria.
>> Per  and , kernel.org accounts "are usually reserved for subsystem
>> maintainers or high-profile developers", but apparently it's at the
>> kernel.org admins discretion to decide whether one is ultimately
>> eligible or not. Do we want the kernel.org admin to have the final say
>> on who gets to vote? Do we want to encourage people to have kernel.org
>> accounts for no other reason than to vote?
> We are using the "kernel.org account" as a way to verify that you really
> are part of our developer/maintainer community and that you are part of
> the "web of trust" and an actual person.
> That is the goal here, if you know of some other way to determine this,
> please let us know. We went through many iterations of this and at the
> moment, it is the best we can come up with.
Ted's mail seemed like it was thrown around as an idea, not something
you're settling on.
> Also, note that the "kernel.org admin" is really a team of people who
> have been doing this for 9 years, it's not a single person responsible
> for giving out new accounts to people that do not meet the obvious
> requirement levels as published on kernel.org
>> Furthermore, having a kernel.org account imposes the additional
>> requirement that you're part of the kernel developers web of trust,
> That is exactly what we want.
>> i.e. that you've met other kernel developers in person. Which is a kind
>> of awkward requirement for enabling electronic voting to be inclusive to
>> people who can't attend in person.
> Yes, we know that, but it does mean that you are "known" to someone
> else, which is the key here.
>> Seems like having a kernel.org account is just a proxy for the criteria,
>> and one that also lacks transparency, and has problems of its own.
> What is not transparent about how to get a kernel.org account?
There is no way of knowing whether you're eligible to vote until you
apply for a kernel.org account and either get approved or rejected.
The current "obvious" requirement levels are not obvious to me. How many
contributions is enough? Is everyone in MAINTAINERS eligible, or do you
have to be a high-profile maintainer/developer? What is a high-profile
developer? How many people in the web of trust must you have met in
And it actually seems like you think it's a good thing the admin team
can make a subjective decision on the above.
It may seem completely transparent and fair and objective on the
*inside*, but it does not look that way on the *outside*. Which is kind
of the definition of transparent. Or lack of.
>> Not that I'm saying there's an easy solution, but obviously kernel.org
>> account is not as problem free as you might think.
> We are not saying it is "problem free", but what really is the problem
> with it?
Seems that some of what I thought was a bug is a feature for you, so I
suppose it's better to focus on the transparency.
On that note, and since this relates to the charter, how's the "The TAB
shall provide transparent and timely reporting (through any mechanism it
deems appropriate) to the Community at large on all of its activities"
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2020-03-13 10:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 0:19 Laura Abbott
2020-03-12 0:34 ` [Ksummit-discuss] " Laurent Pinchart
2020-03-12 2:20 ` Laura Abbott
2020-03-12 21:28 ` Bird, Tim
2020-03-12 22:58 ` Laura Abbott
2020-03-13 3:19 ` Theodore Y. Ts'o
2020-03-13 8:58 ` Jani Nikula
2020-03-13 9:35 ` [Tech-board-discuss] " Greg KH
2020-03-13 9:41 ` [Ksummit-discuss] [Tech-board-discuss] " Vlastimil Babka
2020-03-13 10:07 ` Greg KH
2020-03-13 10:16 ` Geert Uytterhoeven
2020-03-13 10:37 ` Greg KH
2020-03-13 10:50 ` Geert Uytterhoeven
2020-03-13 12:12 ` [Tech-board-discuss] [Ksummit-discuss] " Steven Rostedt
2020-03-13 14:10 ` [Ksummit-discuss] [Tech-board-discuss] " Jani Nikula
2020-03-13 14:52 ` [Tech-board-discuss] [Ksummit-discuss] " Theodore Y. Ts'o
2020-03-13 15:08 ` Jani Nikula
2020-03-13 15:26 ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-03-13 17:14 ` Bird, Tim
2020-03-13 17:36 ` [Tech-board-discuss] [Ksummit-discuss] " Steven Rostedt
2020-03-13 15:18 ` [Ksummit-discuss] [Tech-board-discuss] " James Bottomley
2020-03-13 10:30 ` Jani Nikula [this message]
2020-03-13 13:05 ` Sasha Levin
2020-03-13 15:42 ` [Tech-board-discuss] [Ksummit-discuss] " Steven Rostedt
2020-03-13 14:59 ` [Ksummit-discuss] [Tech-board-discuss] " Konstantin Ryabitsev
2020-03-13 15:07 ` Jani Nikula
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections -- Change to charter' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).