Well, there's certainly a lot of hot air. And the situation is rather
unfortunate.
It seems to me that:
* The social contract as amended is unambiguous, and prevents the
release of sarge as-is.
Therefore:
* The Developers must decide whether to waive or amend the social
contract. If
Andrew M.A. Cater writes (Re: _Our_ resolution merely affirms the status quo):
I posted a comment a long time ago, which might bear repeating
(something close to the text below IIRC).
The Debian developers changed their policy and fundamental documents
when the Sarge release was 90%
The Condorcet/Cloneproof-SSD GR changed section A.6 of the
constitution with some unexpected effects from the new A.6(3):
1. In a vote where there is a supermajority requirement, the ratio of
votes in in favour to those against must _exceed_ the specified
supermajority ratio.
2. In a vote
Manoj Srivastava writes (Re: What your ballot should look like if you're in favor of
releasing sarge):
On Thu, 24 Jun 2004 19:50:58 +1000, Hamish Moffatt [EMAIL PROTECTED] said:
I think that you can reasonably expect this to happen again next
time the developers feel they are misled.
The attached document details a modification written by Zephaniah E. Hull
and I, which I am proposing as an amendment to the Debian Constitution.
This hopefully solves one or two problems we have identified in Debian,
namely closed teams (new-maintainer, ftp maint etc.), stagnation of these
Manoj Srivastava writes (Constitutional amendment: Condorcet/Clone Proof SSD
vote tallying):
I am formally proposing that we adopt this resolution be
adopted, and I am asking for seconds for this resolution; we need at
least 5 other developers to second this for this to go anywhere.
Well, there's certainly a lot of hot air. And the situation is rather
unfortunate.
It seems to me that:
* The social contract as amended is unambiguous, and prevents the
release of sarge as-is.
Therefore:
* The Developers must decide whether to waive or amend the social
contract. If
Anthony Towns writes (GR Proposal: GFDL statement):
Bcc'ed to -project, -legal and -private; followups to -vote please.
It's been six months since the social contract changes that forbid
non-free documentation went into effect [0], and we're still distributing
GFDLed stuff in unstable [1]. I
Marc 'HE' Brockschmidt writes (question for all candidates):
So, to the question:
Should we amend our constitution to reflect how Debian is structured in
reality, or should the people doing these tasks now be recognized as
delegates of the DPL? What will you do to clarify the situation?
I'm
Mario Lang writes (Re: Nomination):
Marc Haber [EMAIL PROTECTED] writes:
On Sun, Feb 26, 2006 at 12:02:11AM +0100, Joerg Jaspert wrote:
[something]
I find that response utterly inappropriate. It would be inappropriate
even during the campaign.
I guess we are reaching new heights of
Manoj Srivastava writes (Constitutional Amendment GR: Handling assets for the
project):
In order to bring the constitution in line with current needs
and practices of handling assets globally, and allowing the projet to
add and remove partner organizations from the set of
Ian Jackson writes (Re: Constitutional Amendment GR: Handling assets for the
project):
they're numbered 1 to 14, below.
I mean 1 to 15, sorry. I split one of them up during editing :-).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
MJ Ray writes (Re: Constitutional Amendment GR: Handling assets for the
project):
Please will you accept one of those amendments?
My proposed amendments 13, 14 and 15 in my message
[EMAIL PROTECTED]
change this text to:
Organisations holding assets in trust for Debian should
Manoj Srivastava writes (Canonical list of proposal text):
Could I ask the proposers to submit formated renditions of the
proposal for inclusion on the web page? Eeew, what abuse of
power. There is nothing in the constitution that allows the secretary
to impose such additional
Manoj Srivastava writes (Filibustering general resolutions):
Due to a loop hole in the constitution, any group of 6 Debian
developers can delay any general resolution indefinitely by putting
up their own amendment, and every 6 days, making substantiative
changes in their amendment
Russ Allbery writes (Re: The Sourceless software in the kernel source GR):
I don't really know how best to help with the underlying problem here.
Part of the problem is that there are still people who think that we
can rely on procedures to protect us absolutely from people. This is
obviously
Manoj Srivastava writes (Re: Filibustering general resolutions):
I am not sure this is the model we should be following )I know
we are currently not following it at all). Your reading of the
wording means that, strictly speaking, there is only a two week (or
one week, if the DPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hereby propose each of the three draft General Resolutions below.
(Each resolution text is between cut marks like these: -8- -8-).
I would like to request that:
* The Project Leader reduces the minimum discussion period
and the voting period to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Debian Project Secretary writes (Call for votes for GR: : Handling
source-less firmware in the Linux kernel):
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
c2d43675-9efa-4809-a4aa-af042b62786e
[ 1 ] Choice 1: Release
Debian Project Secretary writes (Re: Proposal to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation):
There are three ways policy can be changed:
a) The Technical ctte can do so
b) A group of developers can do so, via a GR, with a 2:1 super
Anthony Towns writes (Re: Proposal to delay the decition of the DPL of the
withdrawal of the Package Policy Committee delegation):
The process is already unnecessary, Manoj can continue to maintain policy
through his membership in the technical committee,
This is unfortunately not true. We'd
Manoj, your conflict of interest here is too severe, I think.
Would you please formally delegate the interpretation of the
constitution with respect to maintenance of policy to someone else ?
I don't think you've been grinding your own axe here but, I would like
to ask you to do us a favour and
Manoj Srivastava writes (Re: Proposal to delay the decition of the DPL of the
withdrawal of the Package Policy Committee delegation):
On Thu, 26 Oct 2006 12:28:51 +0100, Ian Jackson [EMAIL PROTECTED] said:
The TC could decide to make a new person the maintainer of the
policy package
Neil McGovern writes (Re: [GR] DD should be allowed to perform binary-only
uploads):
I'll extract the exact line from the above text for you:
... state the SPI Board's current understanding of who is authorised to
act for the project ...
In this case, the DPL.
Nonsense. If we were to
Manoj Srivastava writes (Re: Debian Project Leader Elections 2007: Draft
ballot):
[ ] Choice 1: Wouter Verhelst
...
[ ] Choice A: None Of The Above
Would it be possible to use just letters, rather than both letters and
numbers ? That will make everything a little less confusing - in
Ben Finney writes (Re: Request for GR: clarifying the license text licensing /
freeness issue):
Ian Jackson [EMAIL PROTECTED] writes:
The status quo is quite fine and should be left as it is.
This doesn't address the concern that motivated this discussion: that
the license texts which have
MJ Ray writes (Proposal: GR to deal with effects of a personal dispute):
There is a lamentable personal dispute between Sven Luther and some
other developers. There have been some attempts at reconciliation and
various offers, but none have succeeded in ending this dispute.
...
1. Sven Luther
Sven Luther writes (Re: Proposal: GR to deal with effects of a personal
dispute):
On Fri, Jun 01, 2007 at 10:39:46AM +0100, Ian Jackson wrote:
[stuff]
I applaud your proposal, [...]
OMG WTF. I'm very sorry everyone. Obviously it must have been a
terrible idea. I take it back.
Ian
Pierre Habouzit writes (Re: Proposal: GR to deal with effects of a personal
dispute):
I understand you're upset by all the fuss, that you're frustrated with
the amount of crappy mail it generated. Everybody is. But that does not
gives you any right to be an asshole.
Well, I thought it was
Josip Rodin writes (electing multiple people):
So, I proposed the following addition to the section A.6. Vote Counting
(part of appendix A Standard Resolution Procedure):
As I've said in the meeting at Debconf and on debian-project, I think
this is the wrong way to do because this voting system
The Technical Committee (and those interested in the libc's resolver
behaviour) are having some trouble because of an off-by-one error in
the supermajority specification in recent versions of the
constitution.
This was discussed in
http://lists.debian.org/debian-ctte/2004/05/msg00027.html
and
Pierre Habouzit writes (Re: Supermajority requirement off-by-one error, and TC
chairmanship):
And FWIW, I don't think TC failed to rule because of the majority
rules, but just because the issue was technically not easy to solve at
that time.
The TC would have decided if the supermajority
Anthony Towns writes (Technical committee resolution):
I've been thinking for a while [0] it'd be good to do a real revamp of
the tech ctte. It's been pretty dysfunctional since forever, there's
not much that can be done internally to improve things, and since it's
almost entirely
Russ Allbery writes (Re: Technical committee resolution):
(2) here is again a question of follow-through, and I don't see how your
proposal addresses that. The problem again is that someone has to do
work, and you can't, in general, find people to do work by doing
governance shuffling.
Russ Allbery writes (Re: Technical committee resolution):
This, however, I find a really interesting argument. I'm not sure it
would actually work, but using the tech-ctte as a final arbitrator of
Policy decisions and actually using that appeal on a regular basis is
something that Manoj and I
Russ Allbery writes (Re: Technical committee resolution):
So, I could start doing this right now if you'd like. Manoj and I have a
handful of Policy bugs that we've tagged dubious and that I was planning
on closing at some point. I could just go close them all and refer people
to the
Russ Allbery writes (Re: Technical committee resolution):
That would mean expanding the size of the tech-ctte rather than rotating
its membership, correct?
Yes.
Although we don't have a working removal mechanism either, and that
definitely needs to be fixed.
Ian.
--
To UNSUBSCRIBE, email
Julien Cristau writes (Re: Technical committee resolution):
On Tue, Mar 11, 2008 at 20:03:57 -0400, Hubert Chathi wrote:
OK, the rest of your mail sounds somewhat reasonable, to an outsider who
has no experience whatsoever with TC, but ... given that the TC often
deals with contentious
Manoj Srivastava writes (Re: Technical committee resolution):
Redoing the new blood thing once again is unlikely to have much
of an effect, really. I think we need to find some of the root causes
of the malaise that affects this institution, and fix that, rather
than rampaging
Anthony Towns writes (Re: Technical committee resolution):
Well, if you assume change isn't going to change anything, then, well,
I guess you've got your conclusion.
That's a completely wrongheaded way of looking at it.
We (Manoj, Russ, I, and perhaps others) are not opposed to change.
It must
Josip Rodin writes (Re: Technical committee resolution):
Instead, I would suggest to do two things - first, institute a better
process, one that doesn't so much focus on intricate stalemates (like the
present 6.2 does), but one that focuses on how to generally get things done
- such as a
OK, here is a go at some personal observations:
The main symptom of the TC's brokenness is that it is not making
decisions, or not making them fast enough. I haven't heard anyone
suggest that the TC is actually making wrong decisions.
The causes seem to include:
* Some TC members not being
Josselin Mouette writes (Re: Technical committee resolution):
On jeu, 2008-03-27 at 19:06 +, Ian Jackson wrote:
The main symptom of the TC's brokenness is that it is not making
decisions, or not making them fast enough. I haven't heard anyone
suggest that the TC is actually making
Joey Hess writes (Re: Technical committee resolution):
Ian Jackson wrote:
The causes seem to include:
Isn't the main cause that the Technical Committee is well, a committee?
(Recall the old saying about many heads and no brain.)
That seems to be the core reason for all the problems you
Joey Hess writes (Re: Technical committee resolution):
Ian Jackson wrote:
I haven't heard anyone suggest that the TC is actually making wrong
decisions.
Well..
#104101: The TCs resolution that kernel sould have VESA fb compiled in
was ignored by its maintainer, who instead waited
Loïc Minier writes (Re: Technical committee resolution):
On Thu, Mar 27, 2008, Ian Jackson wrote:
So I would like to suggest something radical. The decisionmaking
processes of the TC should be taken out of the Constitution. Instead,
the TC and the DPL should decide between them a Charter
Joey Hess writes (Re: Technical committee resolution):
Ian Jackson wrote:
So these two don't seem necessarily to indicate that the decisions
were wrong, just that they were ignored. There has indeed been a
problem with TC decisions being ignored.
The TC is the decision-maker of last
Manoj Srivastava writes (Re: Technical committee resolution):
As RMS would say on emacs-dev; a decision like this should be
made by polling the suers (not a vote -- polling them for opinions
_and_ reasons.
The TC would have been equally wrong body to make this decision.
Martín Ferrari writes (Re: Technical committee resolution):
Ok, I was thinking and speaking about limiting hats in a context of
doing it project-wise, not only to the ctte. Sorry for the confusion.
The TC is in fact the very worst place to be thinking about limiting
the number of other hats of
Manoj Srivastava writes (I hereby resign as secretary):
I am hereby resigning as secretary, effective immediately.
I'd just like to join all the other people saying that it's sad that
we have come to this. As you know I haven't always agreed with your
decisions :-) but they have always
I agree with much of the criticism of the outgoing Secretary's actions
in the Lenny GR vote. But I think we need to look to see how this
came to pass.
In my view the mistake came when the project voted to entrench the
Foundation Documents by requiring a 3:1 supermajority to change them.
This
Raphael Hertzog writes (Re: Coming up with a new Oracle (was: Re: First call
for votes for the Lenny release GR)):
On Tue, 06 Jan 2009, Ian Jackson wrote:
- The Secretary should explicitly have the power to delay a GR
vote by up to (say) two weeks for the purposes
Clint Adams writes (Re: Coming up with a new Oracle (was: Re: First call for
votes for the Lenny release GR)):
On Tue, Jan 06, 2009 at 10:09:52AM +0100, Raphael Hertzog wrote:
The constitution should really be clear so that interpretation is almost
never needed.
Agreed.
We
Matthew Vernon writes (Re: Purpose of the Constitution and the Foundation
Documents):
[Ian Jackson:]
- To help voters choose, the following people should be able to
require the Secretary to quote on each GR ballot form a URL
of their choice, to be used by them for disseminating
Ean Schuessler writes (Re: Purpose of the Constitution and the Foundation
Documents):
[Ian Jackson] wrote:
A. De-entrenchment: this is very unlikely to achieve the required
supermajority. But it should be on the ballot anyway when
we put this mess to a vote after lenny.
...
B
Raphael Hertzog writes (Re: Coming up with a new Oracle (was: Re: First call
for votes for the Lenny release GR)):
On Tue, 06 Jan 2009, Ian Jackson wrote:
[Raphael:]
I agree with the intent but I don't agree with the list of persons you
selected. I would restrict
Robert Millan writes (Re: Results of the Lenny release GR):
Actually, I accept the outcome of the last vote. I don't like that we made
an exception for firmware, but the developers chose to make one so there's no
point in arguing about it.
On the other hand, it appears that the Secretary,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lucas Nussbaum writes ([Amendment] Reaffirm current requirements for GR
sponsoring):
I hope that Bill Allombert will rescind his own amendment. If he chooses
to keep it, I might rescind this one instead (we don't need two keep
things as is options
Chris Knadle writes (Re: [all candidates] Removing or limiting DD rights?):
The #1 kind of bug reports that become problems are ones that go like this:
- bug reporter: writes polite and detailed bug report
- maintainer : *cloeses bug* without discussion
(usually within
Ian Jackson writes (Re: [all candidates] Removing or limiting DD rights?):
...
If in this situation there is a possibility of the submitter's
experience being turned into an improvement in the software, it could
arise if the submitter
... can investigate further themselves (perhaps
Wouter Verhelst writes (Re: [all candidates] Debian as an FSF Free Software
Distribution):
Personally, I think we shouldn't be worried about the FSF's opinion
regarding the freeness of our distribution any more than the FSF is
worried about our opinion of the GFDL.
My starting point is that
Lucas Nussbaum writes (Re: [all candidates] on distribution-wide changes and
scalability):
On 14/03/13 at 17:55 +0100, Stefano Zacchiroli wrote:
- Debian should decide to use a single VCS (say, Git), for all packages,
uniform repository structure and work-flow, and give by default
Chris Knadle writes (Re: [all candidates] Removing or limiting DD rights?):
On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
The purpose of a bug report is not to help solve the submitter's
problem.
... No, I don't agree with this. I understand that this reteoric
helps explain
Michael Ossipoff writes (Norman Petry and I (Ossipoff) recommended CSSD, but
Schwartz Woodall is a better voting system for Debian):
Example 1:
Sincere preferences:
99: ABC
2: BAC
100: C(A=B)
The A voters rank sincerely, and the B voters defect:
99: AB
2: B
3: C
In Debian's
Guillem Jover writes (GR: Selecting the default init system for Debian):
I think that forcing a decision through the TC at this time was very
premature and inappropriate, [...]
Perhaps surprisingly, I am not entirely opposed to the idea of a GR
for this question.
My reasons are quite different
Russ Allbery writes (Re: GR: Selecting the default init system for Debian):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I do think that the proper process is for the TC to make a decision at
this stage. The way I read the constitution and the context is that it
is the TC's job
Enrico Zini writes (Re: GR: Selecting the default init system for Debian):
A constructive thing that we may do as a project to address the
political side of the matter, is to add to our technical decision a list
of things that we wish our upstreams would do to make all our lives
easier in the
Holger Levsen writes (Re: GR: Selecting the default init system for Debian):
care to explain why you think so?
Russ has given an answer which I agree with.
But more fundamentally for me: if the project as a whole votes to
overrule the TC on this question, but by a constitutionally
insufficient
Guillem Jover writes (Re: GR: Selecting the default init system for Debian):
On Sun, 2014-01-19 at 12:04:17 +, Ian Jackson wrote:
My reasons are quite different to yours: to summarise, it seems to me
that the init system decision involves political questions as well as
technical ones
Neil McGovern writes (Re: GR: Selecting the default init system for Debian):
That would certainly seem to be the case, but it would be illogical for
a group who is happy to be overridden with a lower requirement to be
prevented from doing so!
Quite.
I think it's perfectly possible for a TC
Neil McGovern writes (Re: GR: Selecting the default init system for Debian):
On Mon, Jan 27, 2014 at 05:11:17PM +, Ian Jackson wrote:
Ian - any thoughts on if your tech-ctte constitution GR could address
this?
You mean my TC resolution draft.
Nope, I meant your supermajorty etc
Guillem Jover writes ([Proposal] GR: Selecting the default init system for
Debian):
This is the revised draft GR proposal (please see below); I'm looking
for sponsors now.
I would consider sponsoring a GR, but like others I would like to see
the TC vote first. And, I strongly suggest you trim
Wouter Verhelst writes (Re: GR proposal: code of conduct):
2. The initial text of this code of conduct replaces the mailinglist
code of conduct at http://www.debian.org/MailingLists/#codeofconduct
Is this overriding the listmasters then?
...
I'll leave it up to the secretary to
Ean Schuessler writes (Re: GR proposal: code of conduct):
I feel we must see clearly that the CoC and its related ban punishment
effectively amounts to a nascent court system for the project.
I don't think that's the case and I don't want to see it that way.
A comprehensive ban is
Sam Hartman writes (Re: GR proposal: code of conduct):
I'd be happy to sponsor a resolution that simply adopted the COC as a
position statement of the day and asked the appropriate parties to take
that as the project's current position.
I think the DPL and listmasters can figure out where on
Lucas Nussbaum writes (Next DPL election):
Of course, I don't want to discourage anyone from running in the DPL
election. I must admit that, personnally, I find the idea of a rather
quiet campaign quite appealing.
In general we have managed to keep our DPL elections civilised,
respectful and
Russ Allbery writes (Re: Debian's custom use of Condorcet and later-no-harm):
This change would also fix a different problem that came up during the
debate, namely one of the problems with the 2:1 majority required for a TC
override. Currently, if we have a general project vote on something on
Alexander Wirt writes (Re: GR proposal: code of conduct):
- the CoC, can only be an extension to our (lists.d.o) Coc [1], as there are
missing the mail/list specific parts. I am also not that happy with having
several documents with the name 'Code of Conduct', maybe we can find a
Thue Janus Kristensen writes (Re: Debian's custom use of Condorcet and
later-no-harm):
I am not completely sure, but I think both ways accomplish the same thing,
if you always only use the = criterium.
My way seems more flexible though, since you can use it with = or , or
2/3 majority over
Matthew Vernon writes (Proposal - preserve freedom of choice of init systems):
I wish to propose the following general resolution, and hereby call
for seconds. [...]
Seconded.
Ian.
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
This is probably going to require a 2:1 majority requirement as
written.
Do you agree that the intent can be achieved by something requiring a
1:1 majority ? If so, can you please say how.
If you're going to say
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
If you're going to say we need to replace the TC resolution is
amended with something like we wish that instead the TC had decided
blah, then please
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
On Sun, Mar 02, 2014 at 10:56:20AM +, Ian Jackson wrote:
Matthew Vernon writes (Proposal - preserve freedom of choice of init
systems):
I wish to propose
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
This a GR proposal is a position statement about issues of the day
(as it says in the Notes and rubric.) It's on the subject of init
systems
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote:
Putting the notes and rubric section first might make this clearer
for you to see, but it would make the whole GR text much less clear to
read
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
There is also this decision of the CTTE:
The TC chooses to not pass a resolution at the current time
about whether software may require specific init systems.
Which doesn't have this GR rider text in it,
Paul Tagliamonte writes (Re: Proposal - preserve freedom of choice of init
systems):
Sorry, Ian. I overreated.
Apology accepted. This whole business is quite difficult for
everyone and I too haven't managed to always keep my temper :-/.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to
Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init
systems):
On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
That doesn't contradict the GR. If the GR passes we have two
resolutions:
11th Feb as modified by GR: sysvinit as default, loose coupling
Nikolaus Rath writes (Re: Proposal - preserve freedom of choice of init
systems):
I believe the point of contention is that Ian seems to imply that due to
the way that the wrote the GR clause, *any* GR related to init would
automatically nullify the TC's decision about the default init system
Tollef Fog Heen writes (Re: Proposal - preserve freedom of choice of init
systems):
]] Russ Allbery
(Dropped DAM and personal Ccs)
(Dropped -project)
The previous decision does say that it is replaced completely by the
text of such a position statement and I do note that the proposed GR
Russ Allbery writes (Re: Proposal - preserve freedom of choice of init
systems):
Since, in my opinion, this question is all about how the project wants to
govern itself and how we want to handle assigning responsibility for work
I don't think this is the right way to look at it. We are a
Sam Hartman writes (Willing to propose option A):
I prefer option A from the TC ballot to Matthew's proposal. However, I
think I prefer no vote to a GR on option A. So, I'm going to hold off
to see if Matthew's proposal gets sufficient seconds before doing
anything.
That is a sensible
Ansgar Burchardt writes (Re: Proposal - preserve freedom of choice of init
systems):
So if someone packages a new init system that is not compatible with
existing init scripts (e.g. if it does not support /etc/init.d/* as a
fallback), then it won't be able to start any service.
This point was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Wouter Verhelst writes (GR proposal: code of conduct):
This is to propose a general resolution under §4.1.5 of the constitution
to propose a Debian code of conduct.
I second this proposal.
Ian.
-BEGIN PGP SIGNATURE-
Version: GnuPG
Kurt Roeckx writes (Re: GR proposal: code of conduct):
On Thu, Mar 06, 2014 at 05:08:10PM +, Ian Jackson wrote:
Wouter Verhelst writes (GR proposal: code of conduct):
This is to propose a general resolution under §4.1.5 of the constitution
to propose a Debian code of conduct.
I
Cyril Brulebois writes (Re: GR proposal: code of conduct):
Kurt Roeckx k...@roeckx.be (2014-03-06):
As far as I can tell the problem is that you're not using MIME and
the same problem people have when voting using non-ASCII
characters.
Conveniently published not so long ago:
(Dropped -project)
Kurt Roeckx writes (Re: GR proposal: code of conduct):
Wouter, are you going to accept Neil's amendment, or should I
create 2 options?
Wouter, please don't accept Neil's second amendment (the one
disallowing modification by the DPL). If you do I shall have to
propose
Lucas Nussbaum writes (Re: All DPL candidates: level of team management):
Unfortunately, [the constitution] prevents delegations that document
processes, [...]
I think that the best solution here is a compromise solution: continue to
document the team's tasks, processes and interactions in
The fix to the constitutional supermajority bug has been delayed
rather. Sorry about that. I have drafted what I think is an
implementation of our conclusions here and in the TC.
Opinions welcome.
Thanks,
Ian.
- GENERAL RESOLUTION STARTS -
Constitutional Amendment: TC
We have accumulated the following GR proposals, mostly to do with TC
matters:
* Fix the supermajority bug. Status: draft text on -vote just sent.
* Change the committee size to an odd number to minimise use of the
casting vote in highly contested situations. Status: under
discussion;
1 - 100 of 296 matches
Mail list logo
