lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 24 Aug 2007 14:13:20 +0200
From:	Jes Sorensen <jes@....com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Tech Board Discuss 
	<Tech-board-discuss@...ts.linux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andy Isaacson <adi@...apodia.org>,
	Josh Boyer <jwboyer@...il.com>, ksummit-2007-discuss@...nk.org
Subject: Re: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux	Foundation
 Technical Advisory Board Elections

Matthew Wilcox wrote:
> On Fri, Aug 24, 2007 at 06:54:14AM +0200, Adrian Bunk wrote:
>> My impression as an SPI member is that in practice most SPI members come 
>> from the SPI projects [1], and due to Debian's size Debian developers 
>> are the majority of SPI members.
> 
> That's true -- but bear in mind that most SPI members are inactive, and
> don't even vote for SPI leader.  I doubt most existing members could be
> bothered to vote for Linux Foundation TAB.

Hi,

It was fair enough to run the vote at KS last year to get the TAB
started in the first place. However limiting the vote to a small closed
cabal, for the future, pretty much ensures that anyone will ever stand a
chance to challenge the board if they felt a change of direction was
needed. I don't have the old emails at hand, but I thought it was stated
clearly last year that the intention was to change the process for the
future?

Personally I am not sure whether SPI would be the right way to do it or
not, I am a bit wary of it being too Debian biased, but I could be
convinced otherwise.

Given that the git commit rate has already been used for a number of
appointments, and partially to select the cabal which currently have the
option to vote for the TAB. It seems pretty to set a threshold such that
anyone with more than X commits (random number out of a hat, say 5) will
get a vote - one vote per person. This avoids the issue of people who
send out 317 patches of one-liners for comments to the MAINTAINERS file
will gain an unproportional number of votes. I don't have the impression
that there is a hierachy within the KS attendees providing them a number
of votes based on their number of contributions either?

Regards,
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ