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

Re: Debian Maintainers GR Proposal, updated

On Wed, Jun 27, 2007 at 12:41:35PM +0100, Anthony Towns wrote:
> Okay, here's a new draft with the following changes: [...]

Okay, as per A.2 I'm calling for a vote on this. TTBOMK there aren't any
related proposals or amendments to add to the ballot, so it should take
the form:

   [   ] Choice 1: Endorse the concept of Debian Maintainers
   [   ] Choice 2: Further discussion

A WML page for vote_003.wml is attached, that I hope is suitable.

(As per A.1(6) I've fixed a couple of typos that were noted by Anibal
and Steve, and reformatted the proposal in HTML)

<define-tag pagetitle>General Resolution: Endorse the concept of Debian Maintainers</define-tag>
<define-tag status>D</define-tag>
# meanings of the <status> tag:
# P: proposed
# D: discussed
# V: voted on
# F: finished
# O: other (or just write anything else)

#use wml::debian::template title="<pagetitle>" BARETITLE="true" NOHEADER="true"
#use wml::debian::toc
#use wml::debian::votebar


# The Tags beginning with v are will become H3 headings and are defined in 
# english/template/debian/votebar.wml
# all possible Tags:

# vdate, vtimeline, vnominations, vdebate, vplatforms, 
# Proposers
#          vproposer,  vproposera, vproposerb, vproposerc, vproposerd,
#          vproposere, vproposerf
# Seconds
#          vseconds,   vsecondsa, vsecondsb, vsecondsc, vsecondsd, vsecondse, 
#          vsecondsf,  vopposition
# vtext, vtextb, vtextc, vtextd, vtexte, vtextf
# vchoices
# vamendments, vamendmentproposer, vamendmentseconds, vamendmenttext
# vproceedings, vmajorityreq, vstatistics, vquorum, vmindiscuss, 
# vballot, vforum, voutcome

    <vtimeline />
    <table class="vote">
        <th>Proposal and amendment</th>
        <td>Thursday,  21<sup>st</sup> June, 2007</td>
        <td>Wednesday, 27<sup>th</sup> June, 2007</td>
        <th>Discussion Period:</th>
        <td>Wednesday, 27<sup>th</sup> June, 2007</td>
        <td>Saturday,  21<sup>st</sup> July, 2007</td>
        <th>Voting Period</th>
        <td>Sunday,  22<sup>nd</sup> July, 00:00:00 UTC, 2007</td>
        <td>Sunday,   5<sup>th</sup> August, 00:00:00 UTC, 2007</td>

    <vproposer />
      Anthony Towns
       [<a href="mailto:ajt@debian.org";>ajt@debian.org</a>]
       [<a href="http://lists.debian.org/debian-vote/2007/06/msg00199.html";>&lt;20070627114135.GA25831@azure.humbug.org.au&gt;</a>]
    <vseconds />
      <li> Martin F. Krafft
        [<a href="mailto:madduck@debian.org";>madduck@debian.org</a>]
      <li> Neil McGovern
        [<a href="mailto:neilm@debian.org";>neilm@debian.org</a>]
      <li> Moritz Muelenhoff
        [<a href="mailto:jmm@debian.org";>jmm@debian.org</a>]
      <li> Steve Langasek
        [<a href="mailto:vorlon@debian.org";>vorlon@debian.org</a>]
      <li> Raphael Hertzog
        [<a href="mailto:hertzog@debian.org";>hertzog@debian.org</a>]
      <li> Antti-Juhani Kaijanaho
        [<a href="mailto:ajk@debian.org";>ajk@debian.org</a>]
      <li> Guilherme de S. Pastore
        [<a href="mailto:gpastore@debian.org";>gpastore@debian.org</a>]
      <li> Enrico Zini
        [<a href="mailto:enrico@debian.org";>enrico@debian.org</a>]
      <li> Alexander Schmehl
        [<a href="mailto:tolimar@debian.org";>tolimar@debian.org</a>]
      <li> Anibal Mosalve Salazar
        [<a href="mailto:anibal@debian.org";>anibal@debian.org</a>]

    <vtext />
    <p> Choice 1. 
      The actual text of the resolution is as follows. Please note
      that this does not include supporting or opposing arguments
      or rationales.  These may be found on the debian-vote mailing
      list archives.
    <h2>General Resolution: Endorse the concept of Debian Maintainers</h2>

    <p>The Debian Project endorses the concept of "Debian Maintainers"
    with limited access, and resolves that:</p>

    <p>A new keyring will be created, called the "Debian maintainers
    keyring". It will be initially maintained by:</p>

      <li> Anthony Towns (proposer, ftpmaster, jetring developer) </li>
      <li> Joey Hess (jetring developer) </li>

    <p>Commit access will also be provided to others in Debian with
    similar roles to ensure that any problems relating to this keyring can
    be dealt with by multiple people. These people will initially be:</p>

      <li> Brian Nelson (n-m frontdesk)
      <li> Christoph Berg (n-m frontdesk, jetring developer)
      <li> James Troup (DAM, ftpmaster, keyring-maint)
      <li> Joerg Jaspert (DAM)
      <li> Marc Brockschmidt (n-m frontdesk)
      <li> Michael Beattie (keyring-maint)
      <li> Ryan Murray (ftpmaster)

    <p>The keyring will be handled using suitable technology to ensure
    it can be maintained by a team. It is expected it will initially be
    maintained in alioth subversion using the jetring tool, and that
    the keyring will be packaged for Debian and regularly uploaded
    to unstable.</p>

    <p>The team will be known as the Debian Maintainer Keyring
    team. Changes to the team may be made by the DPL under the normal
    rules for delegations.</p>

    <p>The initial policy for an individual to be included in the keyring
    will be:</p>

      <p>that the applicant acknowledges Debian's social contract,
      free software guidelines, and machine usage policies.</p>
      <p>that the applicant provides a valid gpg key, signed by a Debian
      developer (and preferably connected to the web of trust by multiple
      <p>that at least one Debian developer (preferably more) is willing
      to advocate the applicant's inclusion, in particular that the
      applicant is technically competent and good to work with.</p>

   <p>All additions to the keyring will be publicly announced to the
   debian-project list.</p>

   <p>The initial policy is that removals from the keyring will occur
   under any of the following circumstances:</p>

      <li> the individual has become a Debian developer </li>
      <li> the individual has not annually reconfirmed their interest </li>
      <li> multiple Debian developers have requested the individual's
          removal for good reason, such as problematic uploads, unfixed
          bugs, or being unreasonably difficult to work with </li>
      <li> the Debian Account Managers have requested the removal </li>

   <p>The initial policy for Debian developers who wish to advocate a
   potential Debian maintainer will be:</p>

      <li> <p> Developers should take care whom they choose to advocate,
      particularly if they have not successfully participated as an
      Application Manager, or in other mentoring roles. Advocacy should
      only come after seeing the individual working effectively within
      Debian, both technically and socially.</p> </li>

      <li> <p> Advocacy messages should be posted to debian-newmaint
      or other relevant public mailing list, and a link to that mail
      provided with the application.</p> </li>

      <li> <p> If a developer repeatedly advocates individuals who
      cause problems and need to be removed, the Debian Maintainer
      Keyring team may stop accepting advocacy from that developer. If
      the advocacy appears to be malicious or particularly careless,
      the Debian Account Managers may consider removing that developer
      from the project.</p> </li>

   <p>The initial policy for the use of the Debian Maintainer keyring with the
   Debian archive will be to accept uploads signed by a key in that keyring

      <li> none of the uploaded packages are NEW </li>

      <li> the Maintainer: field of the uploaded .changes file corresponds
      with the owner of the key used (ie, non-developer maintainers may
      not sponsor uploads) </li>

      <li> none of the packages are being taken over from other source
      packages </li>

      <li> the most recent version of the package uploaded to unstable
      or experimental includes the field "DM-Upload-Allowed: yes" in
      the source section of its control file </li>

      <li> the most recent version of the package uploaded to unstable
      or experimental lists the uploader in the Maintainer: or Uploaders:
      fields (ie, non-developer maintainers cannot NMU or hijack packages) </li>

      <li> the usual checks applied to uploads from Debian developers pass </li>

   <p>The initial relationship to the existing new-maintainer (n-m)
   procedure will be as an independent means of contributing to
   Debian. This means, among other things, that:</p>

      <li> Applicants in the n-m queue may choose to apply to be a Debian
      maintainer while finishing their application or waiting for it to
      be accepted. </li>

      <li> Individuals may apply to the n-m process, and pass through
      it without becoming a Debian maintainer at any point. </li>

      <li> Individuals may apply to become a Debian Maintainer without
      being in the n-m queue, or having any intention of joining the
      n-m queue. </li>

      <li> Application Managers may advocate their n-m applicants but
      are not required to. They may decide to only advocate applicants
      who have passed some (or all) of the T&S or P&P checks. </li>

   <p>There is no initial policy or plans for use of the keyring outside
   the archive. Individuals who wish to reuse the keyring for granting
   access to services to some or all Debian Maintainers may do so
   according to their own judgement, of course.</p>

   <p>In particular, this means that Debian maintainers do not participate
   in the general resolution procedure defined in the Debian constitution,
   and cannot vote in Debian elections.</p>

    <vquorum />
        With the current list of <a href="vote_003_quorum.log">voting
          developers</a>, we have:
#include 'vote_003_quorum.txt'
#include 'vote_003_quorum.src'

    <vstatistics />
      For this GR, as always 
      <a href="suppl_003_stats">statistics</a>
      shall be gathered about ballots received and acknowledgements
      sent periodically during the voting period.  Additionally, the
      list of
      <a href="vote_003_voters.txt">voters</a>
      would be made publicly available. Also, the
      <a href="vote_002_tally.txt">tally sheet</a>
      may also be viewed after to voting is done (Note that
      while the vote is in progress it is a dummy tally sheet).

    <vmajorityreq />
      The proposal needs simple majority.
#include 'vote_003_majority.src'

    <voutcome />
#include 'vote_003_results.src'

        <a href="mailto:srivasta@debian.org";>Manoj Srivastava</a>

Attachment: signature.asc
Description: Digital signature

Reply to: