On 07/02/14 at 12:35 +0100, Joerg Jaspert wrote: > Am 07.02.2014 11:24, schrieb Lucas Nussbaum: > >The Debian Policy team defines Debian's technical framework, > >including > >the structure and contents of the Debian archive > > So, the FTPTeam just got that ripped out of their gut. > Which means we can stop doing NEW and in a slightly more extreme > interpretation > even stop all our cronjobs. We are no longer the ones doing the > contents, > so how could we accept anything? > > The part about the structure is also very debatable, this has also > been a part > of FTPMaster in the past. I can see a small point in sharing this > with the team > that writes down Policy, but thats a small one. > > I think someone here has not thought about this text.
Given the discussion that followed the previous delegation update, I tried to make sure that this one wouldn't raise any concerns, so I assure you that I thought about this text. :-) Additionally, that text was sent for review to 8 people: - Ian, as the one who raised the concerns about the previous version - the Debian project secretary and his assistant - the policy editors delegates - Zack, as the DPL who wrote the previous version of the delegation None of them had any concerns with the text. But, since you think that this delegation can be interpreted as conflicting with the ftpmasters delegation, let me clarify. [ what follows might be too precise for a delegation text, the goal here is to give an idea of the general spirit through some examples ] Policy editors define Debian's technical framework, which is documented in the Debian Policy Manual. That includes deciding on things such as which archive areas (main, contrib, non-free) are needed in the archive [that's *structure*], and define the general rules about what goes in each section [that's *contents*]. They also define the list of priorities (required, important, etc.) [*structure*] and define the criteria for each priority [*contents*]. Regarding sections (admin, text, python, etc.), they delegate the decisions on maintaining the list of sections, and their respective contents, to the archive maintainers (see Policy, 2.4). FTP masters maintain the archive. They decide how files and directories are organized on Debian archive repositories, provided that this does not conflict with the general framework defined by the Policy editors. They also decide, for each package, whether the suggestion made by the maintainer (on archive area, priority, section, etc.) is a valid one, by implementing and interpreting what is defined by the Policy Editors, and in the DFSG (e.g. what is acceptable in main/contrib/non-free). They are also responsible for the general consistency of the archive. On 07/02/14 at 12:55 +0100, Ansgar Burchardt wrote: > Besides the issue Joerg raised, do you change the Policy team's role > from /documenting/ consensus (as mentioned in Policy 1.3) to actually > /defining/ policy? Yes. See the email from the Secretary on that issue [1]: > This means that delegations should take care not to perscribe any > particular process, or method for working that a delegate should adhere > to. It is up to the delegate(s) to form a team and to produce a process > themselves. It is, of course required as above that delegates should > attempt to implement good technical decisions and/or follow consensus > opinion. [1] https://lists.debian.org/debian-project/2014/01/msg00054.html If I delegate "defining policy" to the Policy Editors, I cannot at the same time require that they will do that by following consensus, as that would prescribe a particular process (8.2). However, as per constitution 8.3, Policy Editors "[..] should [...] follow consensus opinion." More concretely, If they were considering changes that impact the work of ftpmasters, it would expected from them to discuss those changes beforehand with ftpmasters. Policy Editors have a track record of seeking consensual positions, so I would be extremely surprised if they did not do that. There's also the question of the split of roles between the Policy Editors and the Technical Committee: The Policy Editors are in charge of the initial and detailed design of the technical policy. If there's disagreement, the issue can be brought to the technical committee (which requires a simple majority to rule on technical policy, see 6.1.1). I would like to add something else: I don't think that one should read delegations in search of loopholes that would give some team more powers than what is generally understood. Writing delegations that are at the same time not too prescriptive, and descriptive enough, is already quite hard. It would be near-impossible to write them as strict legal texts that avoid all loopholes, while still not making them too prescriptive. What matters is the general spirit. Requests for clarification are welcomed, as well as, generally, talking with teams that are impacted or have an impact on one's work. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140207125848.ga16...@xanadu.blop.info