[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: first proposal for a new maintainer policy



Hi,
>>"Raul" == Raul Miller <rdm@test.legislate.com> writes:

Raul> "Guy" == Guy Maor <maor@ece.utexas.edu> writes:
Guy> The constitution places no limitations on the developer's
Guy> authority with regard to their own work. Your version says that
Guy> the maintainers must follow policy.

Raul> Manoj Srivastava <srivasta@datasync.com> wrote:
>> Is that such a bad thing, really? I would rather that the policy
>> documents be corrected, and held as a set of rules htat have to be
>> followed, woth an exception for the items that happen to be in flux
>> (and that means actively debateed at large, not just in the
>> developers mind). The technical committee can then be called upon
>> to interpret this document, and maybe amend it, if needed.

Raul> Let's say we have an no-exceptions that only packages which
Raul> follow policy are accepted in our ftp archive. Does that mean
Raul> that every time a bug is found, where the package violates
Raul> policy, that the package should be removed from the archive?

	You do have a tendency to jump to untenable positions. Who
 said that we shall remove all packages with bugs or all packages that
 fail to follow policy? 

Raul> Let's say someone writes a program which runs packages through a
Raul> series of tests and reveals a bunch of policy violations in many
Raul> packages. What does the iron-clad rule do for us here?

	As with other bugs, we file bugs, and we can say that fix 'em,
 for they violate policy. There is no debate as in "Show me where it
 says we follow policy". And "Well, policy is bunkum anyway, I am
 closing this report".

	Also, people shall be more interested in making sure that
 there are no flaws in the policy, and everyone benefits from that.

Raul> Let's say that in some of these cases any administrative fix
Raul> would seriously damage the integrity of the package... What
Raul> then?

	Then obviously policy is flawed, and one acts to mend
 policy. The bug may or may not remain open, with a note that policy
 is in the process of being amended. If the developers is wrong, in
 the sense that the policy group (which, unlike the technical
 committee is an open group) and/or the committee rule in favour of
 current policy, then the maintainer shall have to fix the bug.

Raul> You've mentioned the code of Hammurabi, and the Magna
Raul> Carta. Last time I checked, Hammurabi hadn't done much coding
Raul> for the linux environment, and the Magna Carta doesn't even
Raul> begin to address software issues.

	I think this deserves little response. It is narrow minded to
 assume that one maynot learn from history; and such arrogance has
 often been the downfall of people, organizations, and nations.

	I prefer not to be blind. Note that I was not planning to
 impement the magna carta or rule that it applied directly to
 Debian (jeez, I thought I was dealing with intelligent people
 and this did not have to be spelled out. My mistake).

Raul> We've already got governments to deal with the business of
Raul> dealing with unpleasant people.

	Well, I could point out that goverments do not expel people
 from Debian, or constrain them to fiollow debian policy. What the
 hell does government have to do with this? Is the concept of the
 advantages of codification of rules too hard for you to digest?

Raul> I think we're getting way off track if we try to deal with
Raul> ourselves as if we're fulfilling that kind of role... [If you
Raul> agree with me on this point, I won't have to go looking up
Raul> references to the government Iceland used to have before the
Raul> king of Norway invaded, for example.>

	Oh, god, this is too stupid to merit a response.


	manoj

-- 
 "ARTICLE NUMBERING IS IRRELEVANT.  ENCOURAGEMENT IS IRRELEVANT.  YOU
 WILL BECOME ONE WITH THE BORG." Martin F. Rose
 (mfrose@caen.engin.umich.edu)
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: