On Sun, Nov 23, 2014 at 02:43:46PM +0100, Stefano Zacchiroli wrote:
On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote:
I think since this is a tie-breaker situation which will presumably
rarely happen, it doesn't really matter much.
How about:
I don't think this is a
Stefano Zacchiroli z...@debian.org writes:
On Sun, Nov 23, 2014 at 09:00:11PM +, Philip Hands wrote:
Stefano Zacchiroli z...@debian.org writes:
If people really want to add a tie breaking rule,
I was mostly trying to get rid of the need for one.
How about just saying that
On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote:
Philip Hands p...@hands.com writes:
Wouter Verhelst wou...@debian.org writes:
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
[...]
2. A member of the Technical Committee is said to be more
On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote:
I think since this is a tie-breaker situation which will presumably
rarely happen, it doesn't really matter much.
How about:
I don't think this is a problem that is worth solving with extra
complexity in the text of the
Stefano Zacchiroli z...@debian.org writes:
If people really want to add a tie breaking rule,
I was mostly trying to get rid of the need for one.
How about just saying that appointments must be done one at a time?
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-|
On Sun, Nov 23, 2014 at 09:00:11PM +, Philip Hands wrote:
Stefano Zacchiroli z...@debian.org writes:
If people really want to add a tie breaking rule,
I was mostly trying to get rid of the need for one.
How about just saying that appointments must be done one at a time?
You mean
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
[...]
2. A member of the Technical Committee is said to be more senior
than another if they were appointed earlier, or were appointed
at the same time and have been a member of the Debian
On Tue, Nov 18, 2014 at 02:44:42PM +0100, Svante Signell wrote:
Hi,
6.2. Composition
1. The Technical Committee consists of up to 8 Developers, and should
usually have at least 4 members.
2. When there are fewer than 8 members the Technical Committee may
On Sat, Nov 22, 2014 at 09:51:44AM +0100, Wouter Verhelst wrote:
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
2. A member of the Technical Committee is said to be more senior
than another if they were appointed earlier, or were appointed
On Sat, Nov 22, 2014 at 10:34:25AM +0100, Stefano Zacchiroli wrote:
On Sat, Nov 22, 2014 at 09:51:44AM +0100, Wouter Verhelst wrote:
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
2. A member of the Technical Committee is said to be more senior
Wouter Verhelst wou...@debian.org writes:
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
[...]
2. A member of the Technical Committee is said to be more senior
than another if they were appointed earlier, or were appointed
at the same
Philip Hands p...@hands.com writes:
Wouter Verhelst wou...@debian.org writes:
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote:
[...]
2. A member of the Technical Committee is said to be more senior
than another if they were appointed earlier, or were
So, let's assume we'd adopted this proposal back in July or so.
And then things happened as they did, and we got the same three
resignations we did.
Perhaps we wouldn't have gotten those same three resignations. I
actually argue that it is a feature to encourage the people who resigned
to do so.
On Fri, Nov 21, 2014 at 12:12:13PM +, Sam Hartman wrote:
1) 2 would expire two people at Jan 1, 2015, meaning the TC had only 3
experienced folks on it.
[...]
4) Anthony's new proposal would schedule the two most senior folks to
expire at end of 2015, right? So you'd have up to 5
Stefano == Stefano Zacchiroli z...@debian.org writes:
[quoting out of order]
I also believe that we should not treat the current situation as
exceptional. This will not be the last time we have a tough
issue before us that takes up a lot of emotional energy. It is
strongly
On Fri, Nov 21, 2014 at 12:41:28PM +, Sam Hartman wrote:
Hmm, are you saying that I should dislike option 4 too because if we
had three resignations in the middle of next year we could get into
the same situation unless some of the resignations were from the
senior members? I actually do
On Fri, 21 Nov 2014 12:12:13 +, Sam Hartman hartm...@debian.org said:
[...]
3) 2-s I think would expire 1 person, because Ian was in s, right?
4) Anthony's new proposal would schedule the two most senior folks to
expire at end of 2015, right? So you'd have up to 5 experienced folks
Lucas == Lucas Nussbaum lu...@debian.org writes:
Lucas (Elaborating on the context a bit given the discussion spread
Lucas over some time -- two options have been proposed: - expire
Lucas the 2 most senior members - expire the 2-R most senior
Lucas members, with R the number of
On Thursday, November 20, 2014 12:33:28 PM Sam Hartman wrote:
Lucas == Lucas Nussbaum lu...@debian.org writes:
Lucas (Elaborating on the context a bit given the discussion spread
Lucas over some time -- two options have been proposed: - expire
Lucas the 2 most senior members -
On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote:
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give above.
Not sure if you've read it Sam, but just in case: I find Phil's example
in
On Thu, Nov 20, 2014 at 08:20:44AM -0500, Scott Kitterman wrote:
Given that we've just had significant turnover in th TC, might it not make
sense to have the first term expirations set for a year or two from now?
That
would keep this discussion well separated from any current turmoil and I
On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org said:
On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote:
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r makes a lot of sense to me for the
reason you give
Hi Phil,
On 19/11/14 at 16:44 +, Philip Hands wrote:
Stefano Zacchiroli z...@debian.org writes:
...
The '2-R' schema could even result in an internal TC discussion: OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just
On 20/11/14 at 13:04 -0500, Hubert Chathi wrote:
On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org said:
On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote:
While I do think that 4-5 years is a good term length, I do think a
lot of churn can be bad, and 2-r
Lucas Nussbaum lu...@debian.org writes:
On 20/11/14 at 13:04 -0500, Hubert Chathi wrote:
On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli z...@debian.org
said:
On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote:
While I do think that 4-5 years is a good term length, I do
Stefano == Stefano Zacchiroli z...@debian.org writes:
Stefano On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote:
While I do think that 4-5 years is a good term length, I do think
a lot of churn can be bad, and 2-r makes a lot of sense to me for
the reason you give
On Thu, Nov 20, 2014 at 05:56:47PM +0100, Stefano Zacchiroli wrote:
[ As a more general status update: as it seems that both the 2 and
2-R model has significant support, I'm working on integrating 2-R
in my Git repo as a separate proposal, so that we can easily vote on
both if they both
On Thu, 20 Nov 2014 21:46:06 +0100, Stefano Zacchiroli z...@debian.org said:
+++ constitution.2-R.txt 2014-11-20 21:37:17.030425658 +0100
...
+or 0 (if R = 2). R is the number of former members of the
+Technical Committee who have resigned, or been removed or
+
On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
Lucas Nussbaum lu...@debian.org writes:
- only resignations from people who would have been expired count in S
FWIW I think either of those deals with the concerns I raised, as it's
going to be way too much effort to game that, and
On Thu, 20 Nov 2014 21:17:11 +, Anthony Towns a...@erisian.com.au said:
On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
Lucas Nussbaum lu...@debian.org writes: - only resignations from
people who would have been expired count in S FWIW I think either of
those deals with the
* Anthony Towns a...@erisian.com.au, 2014-11-20, 21:17:
On Jan 1st of each year the term of any Committee member who has served
more than 42 months (3.5 years) and who is one of the two most senior
members is set to expire on Dec 31st of that year.
would work as a description of that
Anthony Towns a...@erisian.com.au writes:
On Thu, Nov 20, 2014 at 07:51:16PM +, Philip Hands wrote:
Lucas Nussbaum lu...@debian.org writes:
- only resignations from people who would have been expired count in S
FWIW I think either of those deals with the concerns I raised, as it's
going
On 18/11/14 at 11:33 +0100, Stefano Zacchiroli wrote:
Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.
Le mercredi, 19 novembre 2014, 10.13:45 Lucas Nussbaum a écrit :
The '2-R' schema could even result in an internal TC discussion: OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of
expiring the two most
On 19/11/14 at 10:13 +0100, Lucas Nussbaum wrote:
- The main change wrt the original text by Anthony is that the provision
of not expiring senior members if less-senior ones have resigned is
gone. In its stead, there is a provision that inhibits expiries from
reducing the CTTE size
On Wed, Nov 19, 2014 at 10:13:45AM +0100, Lucas Nussbaum wrote:
(Elaborating on the context a bit given the discussion spread over some
time -- two options have been proposed:
- expire the 2 most senior members
- expire the 2-R most senior members, with R the number of resignations
over the
On 19/11/14 at 11:55 +0100, Stefano Zacchiroli wrote:
On Wed, Nov 19, 2014 at 10:13:45AM +0100, Lucas Nussbaum wrote:
Now, let's assume that I'm a member of the TC, not among the two most
senior members, and that I feel a bit exhausted about that, not really
motivated, and not really up to
On Wed, Nov 19, 2014 at 01:20:46PM +0100, Lucas Nussbaum wrote:
This is true only if you use the number of members as the measure for
the strength of the TC. But if instead, you consider the sum of the
experience of all members, more turnover due to resignations at a given
point will have a
Stefano Zacchiroli z...@debian.org writes:
...
The '2-R' schema could even result in an internal TC discussion: OK,
the Project wants us to change two members. Are there people that feel
like resigning now? Or should we just fallback to the default of expiring
the two most senior members?
I
On Wed, Nov 19, 2014 at 11:55:28AM +0100, Stefano Zacchiroli wrote:
That said, I now am convinced that 2 (without salvaging by expiries
of non-senior members) is a better model than 2-R. I've pondered your
arguments below, but I don't find them convincing. Specifically,
Note that with Ian,
On 19/11/14 at 19:21 +, Anthony Towns wrote:
On Wed, Nov 19, 2014 at 11:55:28AM +0100, Stefano Zacchiroli wrote:
That said, I now am convinced that 2 (without salvaging by expiries
of non-senior members) is a better model than 2-R. I've pondered your
arguments below, but I don't find
On Wed, Nov 19, 2014 at 10:09:24PM +0100, Lucas Nussbaum wrote:
I think that the 2-R behaviour is more desirable, as it avoids 2 years
without replacements in 2017 and 2018. Note that this isn't about the
2-R rule as we could have the same behaviour by keeping the 2 rule
and simply dropping
Hi,
Anthony Towns:
Technical Committee members are encouraged to serve for a term of
between three and six years.
What, you seriously want to not increase the amount of Legalese in our
policy? The shame. :-P
and six years as an upper bound since it gives a bit
more flexibility than five
On 18 November 2014 20:33, Stefano Zacchiroli z...@debian.org wrote:
Here is a draft GR text which builds on Anthony's work and implements
some of the aspects discussed in this thread. See below for
comments/rationales and the attachment for a wdiff.
Looks good to me.
+ 3. At
On Tue, Nov 18, 2014 at 10:41:13PM +1000, Anthony Towns wrote:
Looks good to me.
Thanks for your feedback. New draft attached implementing (almost all)
the changes you suggested. The GR text is now also available at
http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=summary
which also
Hi,
6.2. Composition
1. The Technical Committee consists of up to 8 Developers, and should
usually have at least 4 members.
2. When there are fewer than 8 members the Technical Committee may
recommend new member(s) to the Project Leader, who may choose
On Tue, 18 Nov 2014 14:15:25 +0100, Stefano Zacchiroli z...@debian.org said:
7. Term limit:
1. Membership of the Technical Committee is automatically
reviewed on the 1st of January of each year. At this time, the
terms of the 2 most senior members
On Tue, 18 Nov 2014, Stefano Zacchiroli wrote:
On Tue, Nov 18, 2014 at 10:41:13PM +1000, Anthony Towns wrote:
provided /they/ were appointed
This is still pending, and noted in BUGS. I agree this is as a potential
problem, at least if you look at it from a paranoid angle. I find your
Hi Don,
On Dienstag, 18. November 2014, Don Armstrong wrote:
This patch is simple, but:
-1. The Technical Committee consists of up to 8 Developers, and should
+1. The Technical Committee consists of up to 9 Developers, and should
[...]
But if this is at all controversial, then we can
Hi zack@,
Thanks for pushing this subject forward, it's a constitutional change I
would likely second.
Le mardi, 18 novembre 2014, 14.15:25 Stefano Zacchiroli a écrit :
provided /they/ were appointed reads to me like it might mean that
if only one of them was appointed that long ago, maybe
On Tue, 18 Nov 2014, Holger Levsen wrote:
(FWIW, I _think_ I prefer an even number here... and despite labeling
this a game changer I'm not sure I care that much about this
change... arg and this might sound like it could be misunderstood
again...)
The real reason to use an odd number is to
Hi,
On Dienstag, 18. November 2014, Don Armstrong wrote:
The real reason to use an odd number is to avoid having to use the
casting vote in the CTTE. Considering that we've used the casting vote
exactly once in the entire history of Debian, I'm not sure that
including this is worth the effort
On Tue, Nov 18, 2014 at 09:44:43PM +0100, Didier 'OdyX' Raboud wrote:
This is still pending, and noted in BUGS. I agree this is as a
potential problem, at least if you look at it from a paranoid angle.
I find your suggested wording not immediate, though, and I wonder if
a/ someone else has
53 matches
Mail list logo
