Re: Updating the Policy Editors delegation

2014-01-06 Thread Charles Plessy 
Le Mon, Jan 06, 2014 at 04:21:52PM +, Ian Jackson a écrit :
> 
> The policy editors' decisions on the contents of policy (or their
> failure to make such decisions) are subject to review by the TC, as I
> note above.  The TC may overrule the editors with a simple majority.

I still do not understand what is the problem we are trying to solve here.

The bottleneck currently is who is doing the work, and the way it is done for
the Policy is not so different as in other areas: we look for consensus, and
when there are more complains than positive reviews, progresses are difficult.

Said differently, it is easier to find somebody saying that something is not
good than somebody proposing a concrete improvement to the thing.  (I guess
this is also why the Debian website is still managed with CVS…).

We lose momentum because we are are too cautious in the amount of time we give
to people to react to answers.  If I had one change to propose, it would not be
about delegating or not, but about making people's objections void if they do
not answer to a rebuttal within 10 days.  Even something like “please wait
for my answer, I am busy”.  Otherwise, negative opinions become paralysing.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106233651.gs22...@falafel.plessy.net

Re: Debian services and Debian infrastructure

2014-01-06 Thread Luca Filipozzi 
On Mon, Jan 06, 2014 at 10:16:20PM +0100, Daniel Pocock wrote:
> On 05/01/14 14:55, Stefano Zacchiroli wrote:
> > On Sun, Jan 05, 2014 at 02:28:59PM +0100, Joerg Jaspert wrote:
>  Q3. What should be our definition of "official services"?
> >>> Even if this is highly preferable, I don't think that official
> >>> services (.d.o services) should necessarily be running on
> >>> Debian hardware managed by DSA, provided that: - the service is
> >>> clearly useful and used - the service has a sustainable
> >>> maintainance model (active team + instructions on how to
> >>> contribute, run a local copy, etc. + DFSG-free) - the service's
> >>> design does not raise security or scalability concerns
> >> 
> >> I disagree on that, official services should run under project 
> >> overview. So far that the project can take it over and move it,
> >> should all of the team go away. Active team today doesn't mean
> >> they are there tomorrow to properly hand it over. Having the
> >> project itself have access (via DSA at least) ensures it can
> >> continue.
> > 
> > I very much agree with Joerg on this.
> > 
> > A team like DSA offers to the Debian Project two key features.
> > One, which is the most visible one, is the technical output and
> > continued service of a team of talented sysadmins.
> > 
> > The other is the governance guarantee that we, as a project, can
> > always take over the maintenance of a service whose current
> > maintainers go MIA or become unwilling to work with the rest of the
> > project for any reason. As Joerg points out.
> > 
> 
> Disclaimer/conflict of interest: I'm currently proposing a lightweight
> SIP service to run on DSA maintained infrastructure
> 
> For any service, there are some general issues that come to mind for me:
> 
> a) credentials: many services need TLS certificates these days.
> debian.org private keys probably have to be on boxes that DSA control
> and secure and not floating around in shared cloud storage or
> outsourced boxes at arms length

agreed

> b) delegated services: that said, some types of application can
> delegate their security checks (e.g. SIP can use a RADIUS server to
> verify DIGESTs).  In these situations, the service hosting equipment
> does not need to have any copy of the user credentials.  The
> verifications are made in the RADIUS server.  By exposing services
> such as RADIUS, DSA could allow other people to run servers that don't
> need any copies of keys or credentials on their local disks.

we're also concerned about which passwords are entered where; hence
sso.debian.org and the desire to keep distinct the password used for SIP/XMPP
from that used for sudo

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


signature.asc
Description: Digital signature

Re: Debian services and Debian infrastructure

2014-01-06 Thread Daniel Pocock 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 05/01/14 14:55, Stefano Zacchiroli wrote:
> On Sun, Jan 05, 2014 at 02:28:59PM +0100, Joerg Jaspert wrote:
 Q3. What should be our definition of "official services"?
>>> Even if this is highly preferable, I don't think that official
>>> services (.d.o services) should necessarily be running on
>>> Debian hardware managed by DSA, provided that: - the service is
>>> clearly useful and used - the service has a sustainable
>>> maintainance model (active team + instructions on how to
>>> contribute, run a local copy, etc. + DFSG-free) - the service's
>>> design does not raise security or scalability concerns
>> 
>> I disagree on that, official services should run under project 
>> overview. So far that the project can take it over and move it,
>> should all of the team go away. Active team today doesn't mean
>> they are there tomorrow to properly hand it over. Having the
>> project itself have access (via DSA at least) ensures it can
>> continue.
> 
> I very much agree with Joerg on this.
> 
> A team like DSA offers to the Debian Project two key features.
> One, which is the most visible one, is the technical output and
> continued service of a team of talented sysadmins.
> 
> The other is the governance guarantee that we, as a project, can
> always take over the maintenance of a service whose current
> maintainers go MIA or become unwilling to work with the rest of the
> project for any reason. As Joerg points out.
> 

Disclaimer/conflict of interest: I'm currently proposing a lightweight
SIP service to run on DSA maintained infrastructure

For any service, there are some general issues that come to mind for me:

a) credentials: many services need TLS certificates these days.
debian.org private keys probably have to be on boxes that DSA control
and secure and not floating around in shared cloud storage or
outsourced boxes at arms length

b) delegated services: that said, some types of application can
delegate their security checks (e.g. SIP can use a RADIUS server to
verify DIGESTs).  In these situations, the service hosting equipment
does not need to have any copy of the user credentials.  The
verifications are made in the RADIUS server.  By exposing services
such as RADIUS, DSA could allow other people to run servers that don't
need any copies of keys or credentials on their local disks.

c) purpose: we should define some criteria that make the service
compelling.  For example, DSA doesn't provide a full mailbox service,
but a mail forwarding is available.  Personally, I feel that it is
compelling for Debian to offer some SIP and XMPP service on a similar
level to mail forwarding, in particular, because of the strong
position that proprietary alternatives in that space - but maybe that
isn't a criteria that everybody else would value.  What, then, should
the list of criteria be for a service that we value or can't be without?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSyx0kAAoJEOm1uwJp1aqDk14P/R9HqlkhaLrjQ5oExZmj2M46
B6lVTKY3kVUL4dUamkhJ+IiLvl4zJ9ZV4sb4shxFEEPuKt95r18DdnB3EnzcDn7W
SXcENMZgMyCrfsWmrLfjL7ignqpuOnJbJ1TLvVU6S5vcSHnmnrpVSxgZuqYRjevA
ydq+6pM4mtaBiPkuOOKsp0YvQJUe2glTx3gW489ieNEu3Knzj1319g8/qqB7w2K0
mI8LN9nNP6d2Fxi5RwPS2XWSyIXwUc0FhXnBPjWbJVp0bPg7+39CJm4paXKNzk4W
U79mC6u2q6A+ts5rfUVCoycfzfXK067KemRSKSzgZVg8B6FJ4Ez65kTQ5n8K6VNd
hgFYRgXJ9jMpBlWOUAqeiDCMD/MxDKhTQdrhqd5fJO2Cwj/cbbCgZ7oplHha+T6W
hOLgo6ib6iPs297EWl5hD3D9mG07ThCnJGqNtxBM3uESlcCzpBGlp3+DI/zTYALd
24OpswTDa/COIB23C9CwYc0omasSo4pWXm7H8wGoycsRmriYDRV3XOrDC6lltOqm
Vik2SMs+qNBo3GG+BJl/C0s3BK2LgYpavaxecHBKUXeex1fxh5RESUoQmXzVXIZN
QvKJl2T104wxVoKqsi1v9DacSV1Fh4eVmag2Ta9T7/KIYDtNAQSz9XKJ9/eOv9VM
+ZYlb1Bc4jTg/9WOaaYk
=/SaF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cb1d24.9090...@pocock.com.au

Re: Updating the Policy Editors delegation

2014-01-06 Thread Stefano Zacchiroli 
On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote:
> .oO ( funny that this comes up now, given the same delegation text was
> already used in
> https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and 

*nod*

FWIW, the "job description" detailed in that delegation---which I
believe is the first that has been done with the current text---didn't
come out of the blue. It was discussed at length with the policy editors
back then. AFAICT it was consensual between me and them at the time.

This, of course, doesn't necessarily mean the text is bug-free or
non-problematic wrt the Constitution. Bugs happen. But it is what we
collectively believed to be a correct representation of the status quo
back then and of the powers that should be delegated to the Policy
editors.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Updating the Policy Editors delegation

2014-01-06 Thread Neil McGovern 
On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote:
> Doing that now. :-)  Also, I'm more worried with the interactions with
> Constitution 6.1.1. It seems to me that a Policy Editors delegation
> should have come from the TC, not the DPL.
> Dear Secretary, what do you think?
>  

Hia,

Thanks for doing it officially :) Me and Kurt are looking at it now.
There's two conflated issues, but we hope to get a full view out in a
day or two.

Neil
-- 


signature.asc
Description: Digital signature

Re: Updating the Policy Editors delegation

2014-01-06 Thread Peter Palfrader 
On Mon, 06 Jan 2014, Raphael Hertzog wrote:

> On Mon, 06 Jan 2014, Russ Allbery wrote:
> > Ian Jackson  writes:
> > 
> > > This is all very well but I think de jure they aren't a delegated team,
> > > and the distinction is defined in the constitution.  This is not
> > > trivially bypassable, because a delegated team is one who derives their
> > > powers from the DPL and the constitution limits the powers of the DPL.
> > 
> > I believe that deciding on the mechanisms and machinery whereby the
> > project as a whole will work out its technical policy (as opposed to
> > disputes over the contents of that policy itself) falls nicely under 5.1.4
> > and 5.1.9, particularly the latter.
> 
> Agreed, the role of policy editors is to maintain a document. The fact
> that it's also uploaded in Debian as a package is just a technicality.

But whether or not that document has any meaning or influence is a
question for the ftp-masters, release team, and tech-ctte.

The power of the policy maintainers comes from them being listened to by
various teams, but those teams can revoke that and listen to somebody
else or come up with their own documents as and when they see fit.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106191930.ga13...@anguilla.noreply.org

Re: Updating the Policy Editors delegation

2014-01-06 Thread Russ Allbery 
Peter Palfrader  writes:

> But whether or not that document has any meaning or influence is a
> question for the ftp-masters, release team, and tech-ctte.

> The power of the policy maintainers comes from them being listened to by
> various teams, but those teams can revoke that and listen to somebody
> else or come up with their own documents as and when they see fit.

That feels to me like another good reason to have all of that (apart from
the TC) flow from DPL delegations, including the role of editing Policy.
We've not had much trouble with this in the past, but should we ever
unfortunately run into serious coordination issues between those teams, I
think being plugged into the overall project governance method is useful.

To give a hypothetical example, if there was some sort of major conflict
between how Policy was decided (as distinct from what the policy is) and
how the release team was deciding what was important enough to block the
release, or ftp-master deciding what goes into the archive, that feels
like something the DPL (and hence the project through election) should
have delegatable power to sort out.  Not just saying "well, the Policy
team is just maintaining one package in the archive out of many and has no
formal delegated role."

I think it's useful for the project as a whole to have an agreed-upon way
for how we're going to settle most matters of technical policy, since most
of them shouldn't come before the TC at all.  I also think it's best to
have that process overseen by the "democratic" side of Debian governance
(the DPL) as opposed to the "technocratic" side of Debian governance (the
TC), because it's really about cooperation, communication, consensus, and
social norms, not about technical decisions.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iotwewnj@windlord.stanford.edu

Re: Updating the Policy Editors delegation

2014-01-06 Thread Didier 'OdyX' Raboud 
Le lundi, 6 janvier 2014, 16.21:52 Ian Jackson a écrit :
> I think the constitutional position of the policy team is as follows:
> 
> They are a package maintainer team.  They normally make their
> decisions themselves under 3.1.1.

I think that framing the policy team primarily into a package 
maintaining team is unwarrantedly limited: the "Debian policy" is 
primarily a reference document much more than its massaging into a 
package [0].

As the work of that team has quite some impact on the rest of the 
developers' work [1], I feel it is perfectly normal that it is 
delegated, and therefore don't understand how Lucas' latest delegation 
suddenly became a constitutional problem in your eyes.

Cheers,

OdyX

[0] How the Debian policy is shipped in the debian-policy package is
indeed "packaging work", but I see that as an almost-completely
separate activity.
[1] Policy becomes encoded into lintian checks, which then can become
FTP-master auto-rejects; making the compliance effectively 
mandatory.

signature.asc
Description: This is a digitally signed message part.

Re: Updating the Policy Editors delegation

2014-01-06 Thread Raphael Hertzog 
On Mon, 06 Jan 2014, Russ Allbery wrote:
> Ian Jackson  writes:
> 
> > This is all very well but I think de jure they aren't a delegated team,
> > and the distinction is defined in the constitution.  This is not
> > trivially bypassable, because a delegated team is one who derives their
> > powers from the DPL and the constitution limits the powers of the DPL.
> 
> I believe that deciding on the mechanisms and machinery whereby the
> project as a whole will work out its technical policy (as opposed to
> disputes over the contents of that policy itself) falls nicely under 5.1.4
> and 5.1.9, particularly the latter.

Agreed, the role of policy editors is to maintain a document. The fact
that it's also uploaded in Debian as a package is just a technicality.

Would ftpmasters stop being a delegated team the day where they package
dak again ? I don't think so.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106180200.ga2...@x230-buxy.home.ouaza.com

Re: Updating the Policy Editors delegation

2014-01-06 Thread Andreas Barth 
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140106 17:22]:
> Lucas Nussbaum writes ("Re: Updating the Policy Editors delegation"):
> > .oO ( funny that this comes up now, given the same delegation text was
> > already used in
> > https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and 
> > https://lists.debian.org/debian-devel-announce/2013/06/msg4.html)
> 
> Sorry I didn't spot it earlier :-).

Historically I think delegating a policy team started with
https://lists.debian.org/debian-devel-announce/2005/06/msg00017.html



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106173212.gj16...@mails.so.argh.org

Re: Updating the Policy Editors delegation

2014-01-06 Thread Russ Allbery 
Ian Jackson  writes:

> This is all very well but I think de jure they aren't a delegated team,
> and the distinction is defined in the constitution.  This is not
> trivially bypassable, because a delegated team is one who derives their
> powers from the DPL and the constitution limits the powers of the DPL.

I believe that deciding on the mechanisms and machinery whereby the
project as a whole will work out its technical policy (as opposed to
disputes over the contents of that policy itself) falls nicely under 5.1.4
and 5.1.9, particularly the latter.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eh4lgh4j@windlord.stanford.edu

Re: Updating the Policy Editors delegation

2014-01-06 Thread Ian Jackson 
Russ Allbery writes ("Re: Updating the Policy Editors delegation"):
> Ian Jackson  writes:
> > The policy editors will continue to be the maintainers of the policy
> > package, and can change the policy team membership and the policy
> > process as they see fit.  Their substantive decisons are subject to
> > the TC's review.  If they go entirely mad the TC can replace them.
> 
> I would be unhappy about moving in this direction.  We went to some effort
> a while back to convert the Policy Editor role to a delegated role in the
> Debian project, and I continue to think that's appropriate given the
> importance of Policy to the project as a whole.  It provides another level
> of review that can focus on the process and health of the team, as opposed
> to the TC review, which the constitution focuses on the contents of the
> results.
> 
> I would prefer to have the Policy Editors continue to be a delegated
> position for that reason.

This is all very well but I think de jure they aren't a delegated
team, and the distinction is defined in the constitution.  This is not
trivially bypassable, because a delegated team is one who derives
their powers from the DPL and the constitution limits the powers of
the DPL.

Of course if the policy editors want to take advice from the DPL, then
that's fine.

Note also that there are bits of policy that aren't in the
debian-policy package.  I think those have the same status:
self-governing maintainers, whose decisions are subject to review by
the TC.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21194.58706.255601.564...@chiark.greenend.org.uk

Re: Debian services and Debian infrastructure

2014-01-06 Thread Olivier Berger 
Hi.

Enrico Zini  writes:

> On Sun, Jan 05, 2014 at 12:05:18PM +0100, Raphael Hertzog wrote:
>
>> > 1. to improve communication between DSA and service maintainers
>> >+ have an archived, public list where (prospective) service maintainers
>> >  can engage with DSA about stuff they are planning/thinking about.
>> >  (Maybe recycle debian-admin@l.d.o, or use 
>> > debian-services-admin@l.d.o?)
>> debian-services-admin@l.d.o seems to be rather appropriate for this (it's
>> unlikely that this kind of discussion would generate so much mail that the
>> list could no longer serve its current purpose).
>
> debian-services-admin@l.d.o seems to me, too, to be the perfect place
> for it.
>

+1

>> This would be good to have but (someone|DSA) would have to prod service
>> maintainers to get this started, otherwise it will never happen. This
>> requirement could also be mentioned in the document I suggested earlier.
>
> I think we already have something very close to this description here:
> https://wiki.debian.org/Services
>

+1

Both the list and the wiki pages some love from DSA or other project
members, IMHO.

I've tried to ask for information and document the bits I could get, on
recent experiments in the domain of such services, and found it really
hard with very low (none) feedback on my contributions there :-/

Thanks Lucas for bringing this topic to discussion, and hoping the
situation improves.

My 2 cents,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txdhm47i@inf-8660.int-evry.fr

Re: Updating the Policy Editors delegation

2014-01-06 Thread Russ Allbery 
Ian Jackson  writes:

> So, in summary, I think there is nothing to be done here, except
> (ideally) for you to withdraw the delegation statement.

> The policy editors will continue to be the maintainers of the policy
> package, and can change the policy team membership and the policy
> process as they see fit.  Their substantive decisons are subject to
> the TC's review.  If they go entirely mad the TC can replace them.

I would be unhappy about moving in this direction.  We went to some effort
a while back to convert the Policy Editor role to a delegated role in the
Debian project, and I continue to think that's appropriate given the
importance of Policy to the project as a whole.  It provides another level
of review that can focus on the process and health of the team, as opposed
to the TC review, which the constitution focuses on the contents of the
results.

I would prefer to have the Policy Editors continue to be a delegated
position for that reason.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sit1ghoq@windlord.stanford.edu

Re: Updating the Policy Editors delegation

2014-01-06 Thread Ian Jackson 
Lucas Nussbaum writes ("Re: Updating the Policy Editors delegation"):
> .oO ( funny that this comes up now, given the same delegation text was
> already used in
> https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and 
> https://lists.debian.org/debian-devel-announce/2013/06/msg4.html)

Sorry I didn't spot it earlier :-).

> Doing that now. :-)  Also, I'm more worried with the interactions with
> Constitution 6.1.1. It seems to me that a Policy Editors delegation
> should have come from the TC, not the DPL.
> Dear Secretary, what do you think?

The TC doesn't have the power to delegate.  Instead it is the body of
last resort (see 6.3.6).  If no-one is unhappy with the current
composition of the policy maintenance team (which seems to be the
case) then there is no dispute to resolve; if someone was unhappy and
brought it to the TC it would be dealt with under 6.1.2 "who should be
the maintainer of a package".

6.1.1 is for situations such as someone being unhappy with the
specific contents of some bit of policy, and taking it to the TC.
This is not unusual and we have decided such questions in the past.


I think the constitutional position of the policy team is as follows:

They are a package maintainer team.  They normally make their
decisions themselves under 3.1.1.

The policy editors' decisions on the contents of policy (or their
failure to make such decisions) are subject to review by the TC, as I
note above.  The TC may overrule the editors with a simple majority.

The composition of the policy team is a matter primarily for the team
itself.  Their team membership decisions are subject to review by the
TC, if a dispute arises, under 6.1.2 "who".

The policy team's decisions on the policy process are not subject to
review.  The constitutional position is that the TC will instead
review the results of the policy process (or the lack of results), as
I discuss above.  However:

If some group of people felt that the policy process was sufficiently
bad, it would be open to them to suggest that they should take the
package over and run the process in some different way.  If that led
to a dispute the TC could adjudicate it under 6.1.2 "who".  (But this
is all entirely hypothetical: In the current situation I can't imagine
anyone sane wanting to do anything as aggressive as that, and
historically the TC has been reluctant to hand over packages to other
people.)


So, in summary, I think there is nothing to be done here, except
(ideally) for you to withdraw the delegation statement.

The policy editors will continue to be the maintainers of the policy
package, and can change the policy team membership and the policy
process as they see fit.  Their substantive decisons are subject to
the TC's review.  If they go entirely mad the TC can replace them.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21194.55328.562623.103...@chiark.greenend.org.uk

Re: Updating the Policy Editors delegation

2014-01-06 Thread Lucas Nussbaum 
.oO ( funny that this comes up now, given the same delegation text was
already used in
https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and 
https://lists.debian.org/debian-devel-announce/2013/06/msg4.html)

On 06/01/14 at 13:51 +, Neil McGovern wrote:
> On Fri, Jan 03, 2014 at 05:58:19PM +, Ian Jackson wrote:
> > Furthermore, I don't think this delegation declaration is
> > constitutionally appropriate.  The policy editors are, primarily,
> > maintainers of a package.
> > 
> 
> Indeed, there's potentially an issue here that the constitution states
> (8.3) "Delegates may make decisions as they see fit, but should attempt
> to implement good technical decisions and/or follow consensus opinion."
> 
> By defining a process within a delegation, this removes this option,
> which a delegation cannot do.
> 
> > The processes for how to maintain a package, and ordinary
> > maintainership succession, would seem to fall squarely within the
> > current maintainers' own discretion.  Jurisdiction to adjudicate
> > package maintainership disputes, and oversight of the decisions of the
> > policy editors, are explicitly granted to the Technical Committee.
> > 
> > So it seems to me, at the moment, that this delegation is ultra vires
> > and hence not binding on the policy maintainers.
> > 
> 
> Indeed, though please note that this isn't an official interpretation of
> the consitution. If you want that, please mail secretary@ :)

Doing that now. :-)  Also, I'm more worried with the interactions with
Constitution 6.1.1. It seems to me that a Policy Editors delegation
should have come from the TC, not the DPL.
Dear Secretary, what do you think?
 
Lucas


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106143846.ga23...@xanadu.blop.info

Re: Updating the Policy Editors delegation

2014-01-06 Thread Raphael Hertzog 
On Mon, 06 Jan 2014, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: Updating the Policy Editors delegation"):
> > Have you seen some mistakes that would help us (or at least me)
> > understand which problems you're {thinking of,anticipating}?
> 
> I think the biggest problem isn't that the policy editors are making
> mistakes, but that they aren't making enough decisions.  I'd like them
> to make more mistakes :-).

I would feel more confortable if you made that claim after having tried
to play along the current rules. To me it seems more an issue of having
enough time to animate the discussions and draft the texts than anything
else.

Sure there are exceptions on topics which are highly specialized and where
people don't feel qualified to second (the triggers issue comes to my
mind. BTW why didn't you respond to Charles' query? he explicitly asked
a review from you...) but other than that both Russ and Charles managed to
bring multiple issues to completion without too much fuss, just explicitly
seeking for seconds when they thought that an issue was mostly ready to be
merged.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106135344.ga10...@x230-buxy.home.ouaza.com

Re: Updating the Policy Editors delegation

2014-01-06 Thread Neil McGovern 
On Fri, Jan 03, 2014 at 05:58:19PM +, Ian Jackson wrote:
> Furthermore, I don't think this delegation declaration is
> constitutionally appropriate.  The policy editors are, primarily,
> maintainers of a package.
> 

Indeed, there's potentially an issue here that the constitution states
(8.3) "Delegates may make decisions as they see fit, but should attempt
to implement good technical decisions and/or follow consensus opinion."

By defining a process within a delegation, this removes this option,
which a delegation cannot do.

> The processes for how to maintain a package, and ordinary
> maintainership succession, would seem to fall squarely within the
> current maintainers' own discretion.  Jurisdiction to adjudicate
> package maintainership disputes, and oversight of the decisions of the
> policy editors, are explicitly granted to the Technical Committee.
> 
> So it seems to me, at the moment, that this delegation is ultra vires
> and hence not binding on the policy maintainers.
> 

Indeed, though please note that this isn't an official interpretation of
the consitution. If you want that, please mail secretary@ :)

Neil
-- 


signature.asc
Description: Digital signature

Re: Updating the Policy Editors delegation

2014-01-06 Thread Ian Jackson 
Cyril Brulebois writes ("Re: Updating the Policy Editors delegation"):
> Have you seen some mistakes that would help us (or at least me)
> understand which problems you're {thinking of,anticipating}?

I think the biggest problem isn't that the policy editors are making
mistakes, but that they aren't making enough decisions.  I'd like them
to make more mistakes :-).

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21194.43316.919649.745...@chiark.greenend.org.uk

Re: Debian services and Debian infrastructure

2014-01-06 Thread Thijs Kinkhorst 
On Mon, January 6, 2014 11:38, Stephen Gran wrote:
> I don't think jumping straight to a solution that puts all of the
> responsibility for every idea for a service in Debian on DSA shoulders is
> either the only way to go or even a good way to go.  There are plenty
> of bad ideas that should be allowed to wither on the vine, and there
> are always going to be services that have been designed in such a way as
> to be difficult to integrate into DSA-managed infrastructure.  We are,
> after all, a reasonably small team of volunteers.  Pretending that we
> can support an infinite number of services or an infinite variety of
> designs is just going to end in disappointment for someone.

I think this is a good observation. The whole problem does not seem to
differ at all from with the tradeoffs that the sysadmin team in a large
organisation wherein I work, have to make regularly. New services come to
us in a variety of forms: someone just requests functionality and all
other decisions are left to us; someone wants us to host a product or is
developing a product and consults us early on (those people are the
best!); more often someone has already bought or developed some product
and it 'just' needs to be hosted.

It's always a case by case judgement: how essential is this service? Will
this fit in our infrastructure? If not, can we feasibly have it changed so
it will? And if not, sometimes it's decided that we will need to host it
nonetheless, in other cases we advise to host it somewhere else. The
latter is surely an option and it doesn't necessarily mean we completely
lose control over it at all. The simple fact that we retain control over
DNS is a blunt but effective last resort to anything gone bad.

Just like DSA, it's not our job to exclusively host everything that the
organisation requires nor is it required that everything that we do end up
hosting conforms to our ideal of the perfect service.


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/f1fda1389bd5e7727d4294a794afe446.squir...@aphrodite.kinkhorst.nl

Re: Debian services and Debian infrastructure

2014-01-06 Thread Stephen Gran 
This one time, at band camp, Lucas Nussbaum said:
> Hi,
> 
> As previously mentioned[1], I've been talking with DSA about the state
> of Debian services on Debian infrastructure. DSA asked me to move the
> discussion to a public list, which is what I'm doing here.
> What follows is my current state of mind on this question. I'm open to 
> changing my mind based on the project's feedback.
> 
> [1] https://lists.debian.org/debian-project/2013/12/msg00015.html
> 
> 
> The underlying questions that I'd like to answer are:
> 
> Q1. How much should we push for Debian services (services useful to 
> Debian) to be hosted on Debian infrastructure?
> 
> Q2. Should we seek other hosting opportunities to ease Debian services
> development and hosting? Should I authorize the use of Debian money to
> fund infrastructure not managed by DSA, in the case of a useful service
> that DSA has been unable to accept in the infrastructure it manages?
> 
> Q3. What should be our definition of "official services"?
> 
> 
> Background
> ==
> 
> First, it's important to state that DSA has been doing a fantastic job on 
> maintaining our core infrastructure for the last few years. The level of 
> quality and professionnalism of their work clearly surpasses what can be 
> found in most organizations, volunteer or not.

Thank you.

I am speaking largely for myself, but I've discussed this mail with the
team.  Where I use 'we', I speak for the team.

> However, there has been several episodes, involving the development of new 
> services or their move to Debian infrastructure, that generated a lot of 
> frustration and demotivation on both sides (DSA and service developers).
> As examples, one can think of codesearch, or the fedmsg GSOC project.
> There are also services that have been developed outside of Debian's
> infrastructure, with AFAIK no plans to move them to Debian infrastructure.
> The recurring pattern seems to be that, when DSA is approached to move the 
> service to Debian infrastructure, their evaluation of the service's design
> results in changes requests or constraints that the service maintainers
> consider too hard to satisfy.

We think this might come from a fundamental mismatch between what DSA
are willing to host and what some people would like to design.  We
don't think that that's a bad thing: we don't have to host everything
that relates to Debian, any more than the glibc maintainers have to look
after everything written in C.

We are, of course, happy to look after things once they get a little
further along and look like they'll prove useful to the project.

> I'm worried that this situation is harmful for the project. Similarly to 
> how we increased the amount of collaborative packages maintainance over 
> the years, we should improve on collaborative service maintainance, and we 
> should move away from the myriad of unofficial services maintained by a 
> sole DD, and hosted on this DD's personal machine.

Absolutely agreed.

> The obvious way to do that would be to facilitate the hosting of emerging 
> services on Debian infrastructure, and I think that we should all work 
> together to identify what could be done towards that.

We don't agree here.  There are many ways to meet the goal of service
ownership being collaborative, only one of which is to have everything
hosted by DSA.  Another might be that service owners look after their
own hosting and system administration duties themselves, in a team,
and have nothing to do with DSA.  Another might be that DSA act in
an advisory capacity, and assist new services in starting up, and then
recuse ourselves and allow the service owners to look after their service
themselves.  Another might be that there is a mixed mode of support.

I don't think jumping straight to a solution that puts all of the
responsibility for every idea for a service in Debian on DSA shoulders is
either the only way to go or even a good way to go.  There are plenty
of bad ideas that should be allowed to wither on the vine, and there
are always going to be services that have been designed in such a way as
to be difficult to integrate into DSA-managed infrastructure.  We are,
after all, a reasonably small team of volunteers.  Pretending that we
can support an infinite number of services or an infinite variety of
designs is just going to end in disappointment for someone.

> I've given some thought to this myself, and came up with the following 
> ideas.  Some of them are probably really bad ideas, but let's try to 
> brainstorm a bit:
> 
> 1. to improve communication between DSA and service maintainers
>    + have an archived, public list where (prospective) service maintainers
>  can engage with DSA about stuff they are planning/thinking about.
>  (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?)
>    + have DSA provide collective answers more often, rather than a set of 
>  individual answers. It's often not clear if something is a final 
>