Re: call for seconds: on firmware
On Sun, Nov 23 2008, Steve Langasek wrote:
> On Sun, Nov 23, 2008 at 03:13:38PM -0600, Manoj Srivastava wrote:
>> On Sun, Nov 23 2008, Steve Langasek wrote:
>
>> > On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote:
>> >> The constitution does not give release teams the powers to
>> >> override the foundation documents, so the release team can not ignore
>> >> SC violations.
>
>> >> I can make a formal interpretation of the constitution, if you
>> >> wish.
>
>> > 3. Individual Developers
>> > 3.1. Powers
>
>> > An individual Developer may
>
>> > 1. make any technical or nontechnical decision with regard to their own
>> > work;
>
>> Does that mean I can just ignore the DFSG in my packages, and no
>> one can override that? I don't think so.
>
> No, it means that the *secretary* doesn't have special powers to
> decide the DFSG has been violated and a remedy is in order.
I do not. All I have the power to decide is how the vote is
conducted.
> We have lots of other structures in place to override developers when
> we think they've made a decision that's wrong: the ftp team can remove
> packages from the archive; the release team can refuse to release the
> package; the TC and the developers can override the decision via the
> documented processes in the constitution. The secretary is not, and
> should not be, one of the parties with power to directly override
> decisions made by developers, no matter how improper you might think
> they are.
I am not overriding any decision. I am just creating a ballot in
the best means I can see, based on my understanding of the foundation
documents. I am not going to do something I consider unethical just
because other office bearers can correct things, or take up the slack.
The release team can release whatever they please. I am not
modifying dak. Their decision can still be overridden. But the proper
form of the ballot is my responsibility, and I am not going to shirk
it.
You think I am wrong in the decision, ok. I think the release
team and the kernel team were wrong too. I am not interfering with the
kernel image packages (though I do have a certain affinity to them --
the very first auto generated kernel image package was created by me;
they were hand made prior to that).
Bur as a secretary, I have obligations, to the constitution, the
project, and end users, whose rights ought not to be trampled by
non-free crap.
>> > And the DFSG is not a "decision properly made under [the rules of the
>> > constitution]" because the DFSG predates the constitution and has
>> > never been amended or re-confirmed by General Resolution.
>> > (2004/vote_003 only amended the text of the Social Contract, not the
>> > DFSG.) So there's no way that the constitution gives you special
>> > authority in disputes over interpretation of the DFSG, either.
>
>> The constitution has wording on what the foundation documents
>> are, and how they can be overridden. I am interpreting the constitution
>> when it comes to my role, to the best of my ability to do so.
> It has language about how the foundation documents can be
> *superseded*. If you had meant to say "overridden", you should have
> written that when proposing the GR for 2003/vote_0003, instead of
> claiming after the fact that "supersede" implies "override".
I maintain that supsersede and override have no distinction, as
far as I interpret the constitution here. If you think that there
should be a distinction, and the constitution needs to be clarified,
you know where to start the process.
> The Debian Project did not ratify any statement about the circumstances
> under which the foundation documents can be overridden or ignored. That
> doesn't mean overriding the DFSG is *ok*, but it does mean that if you
> assert /in your role as secretary/ that a particular action taken by a
> developer is a violation of the DFSG or SC and therefore not permitted,
> you're legislating from the bench, which harms the integrity of the office
> of Project Secretary overall.
>
>> > (Even if it had been ratified by GR, I find the claim that the Secretary's
>> > powers include deciding whether a developer is "working against" a
>> > constitutional decision to be dubious at best.)
>
>> I can only say what the constitution does or does not allow, and
>> what powers the constitution confers on people. I have no idea of
>> people are working against the constitution or not.
>
> Then on what grounds does the secretary, as interpreter of the
> constitution, have any authority to say that "the constitution does
> not give release teams the powers to override the foundation
> documents"?
Huh? Did I not say, and I quote "I can only say what the
constitution does or does not allow", firstly, while doiung my job, and
secondly, since my role is also that of interpreting the constitution?
I am trying to interpret the constitution based on what is written, and
my memory of the various resolutions ratifying it or amending it;
as consistently as I can.
The secretary is not just a rubber stamp role, just running
votes. You can use devotee for that in an automated fashion (I think I
can add such automation in a couple of people-weeks coding time).
> By my reading, the constitution gives any developer the
> power to make any decision regarding their own work, as long as it a)
> doesn't work against decisions made under the constitution, and b)
> isn't overridden by one of the documented processes.
There were decisions made under the constitution to create
foundation documents that define the boundaries of the debian system,
and that do place further restrictions on what the project, and its
members do.
>> Overriding parts of the foundation documents as you please is
>> tantamound to, and generally indistinguishable from, replacing the
>> document (perhaps temporarily) with a new version.
>>
>> When I wrote that proposal, this is what I did have in mind.
>
> When I seconded it and voted for it, it was not.
Feel free to start an editorial amendment to the constitution to
clarify that section.
manoj
--
Failure is more frequently from want of energy than want of capital.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: