Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

Le vendredi, 6 septembre 2019, 11.32:06 h CEST Bill Allombert a écrit :
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> > > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote:
> > > > >   * Most decisions are not just technical decisions, in many/most
> > > > >   cases
> > > > >   
> > > > > the decisions have answers that are all correct, but it just
> > > > > depends
> > > > > on the weight of specific trade-offs. How those are weighted
> > > > > depends
> > > > > heavily on each individual. This also seems rather unfair, as
> > > > > it's
> > > > > taking the natural and expected biases of a small set of people
> > > > > in
> > > > > the project and forcing them into the entire project.
> > > > 
> > > > Honestly, if the answers are all correct and we've been going around
> > > > in
> > > > circles since like forever, then having a small team decide that one
> > > > of
> > > > these correct answers is now the preferred one and we're going with it
> > > > (after listening to all the arguments) hardly seems unfair to me.
> > > 
> > > But then it become a steering committee and not a technical commitee.
> > 
> > Actually, it seems that the Technical Committee has kinda always been
> > doing
> > both of these things: arbitration, and steering.
> 
> The way the TC members are selected is not compatible with taking the role
> of a steering committee (which need to be properly elected rather than
> self-selected).

Agreed. For me, that's also why "steering" decisions have always been hard: 
hard because handed to the TC at a late stage, as last resort; hard decisions 
to take for the TC, with high stakes and emotions, etc. I feel it's also the 
main reason behind the refusal to _be_ the Roadmap Team from the TC.

> (To avoid misunderstanding, I am not in favor of Debian getting a
> steering committee. The steering should come from the DPL, who is
> elected)

It seems that this is what is intended by the current constitution. But we 
should really discuss what we need; and I'm not convinced that a steering 
group designated by an elected DPL [delegate] is that much better than a self-
selected group vetted by the elected DPL [TC]. If we do give powers to a 
steering group, we could (and I argue we probably should) make it a body of 
elected individuals with fixed terms (renewability, grace periods, term 
overlaps, etc are important details of course).

-- 
OdyX

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

Re: Thinking about Delegating Decisions about Policy

[Didier 'OdyX' Raboud]

Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote:
> > >   * Most decisions are not just technical decisions, in many/most cases
> > >   
> > > the decisions have answers that are all correct, but it just depends
> > > on the weight of specific trade-offs. How those are weighted depends
> > > heavily on each individual. This also seems rather unfair, as it's
> > > taking the natural and expected biases of a small set of people in
> > > the project and forcing them into the entire project.
> > 
> > Honestly, if the answers are all correct and we've been going around in
> > circles since like forever, then having a small team decide that one of
> > these correct answers is now the preferred one and we're going with it
> > (after listening to all the arguments) hardly seems unfair to me.
> 
> But then it become a steering committee and not a technical commitee.

Actually, it seems that the Technical Committee has kinda always been doing 
both of these things: arbitration, and steering.

In arbitration, the TC has had to decide on disagreements; either by looking 
at current documentation or at current practice; ending up ruling about who 
was "right" [0]. It hasn't necessarily always been controversial, or between 
people in disagreement; the TC has also sometimes arbitrated questions put 
forward; pretty much on the tunes of "we're not sure what do here, could you 
tell us with a more distant view what is it that the project expects us to be 
doing?".

Now, in terms of steering, I can think of some past issues: #727708 "default 
init" obviously, #741573 "menu systems",#717076 "JPEG library", etc. In 
these 
cases [1], it hasn't really been about breaking ties, or just arbitrating 
between existing options. The TC really had to agree, and decide which was the 
right [2] path forward, for the good of the Project, really in a "steering" 
position. And by exercising that "steering" function for the project, the TC 
has taken decisions that have put some people off; mostly because, by the mere 
nature of the questions asked, it couldn't satisfy every party, while still 
allowing the project to "go on".


I have come to wonder if these two functions shouldn't be separated, in 
different bodies (eventually with different nomination rules, etc.). This 
"steering" question had also been phrased, slightly differently, by Mehdi, 
during his DPL term, with the idea of a "Roadmap team". [As I understand it, a 
Roadmap team would pilot the Debian ship with a vision on how to sail the 
sees, where the TC, when "steering", decides on a case-by-case in a ship 
without captain]. Uncomfortable, for political and availability reasons, the 
TC declined to take that role back then.

From there, does the project want/need, any of these two bodies?
- an arbitration group, with the power to break gordian knots, and help 
greasing the wheels of the project;
- a steering group, to establish and pilot a vision for the project, deciding 
on conflicting points when needed (several intensity variants are of course 
possible; from a case-by-case steering, to a much "stronger" plan 
enforcement).

My point, I guess, is that the TC is currently doing mostly arbitration (which 
doesn't seem very controversial, but for the affected ones), and a little 
steering (which seems bound to always be controversial). And when it _does_ 
steering, it is constrained by §6.3.5 "No detailed work".

One step forward, could be to completely remove all "steering" powers from the 
TC, to make it a purely arbitration body. But who would decide on the complex 
"steering" issues; who would have decided on the default init system?

Of course, the question of how "progressive" any steering body should be is a 
complex one. As Ian puts it:

Le lundi, 13 mai 2019, 16.28:11 h CEST Ian Jackson a écrit :
> I also think that the TC is far less conservative than it ought to be
> and is much more willing to risk damaging (or is blind to the risk of
> damaging) the project's social cohesion, in the name of what is called
> technical progress but often seems to me to be a narrowing of the
> project's focus.

I don't necessarily agree, but I also clearly understand [3] that when the TC 
said (in #741573), that "(it) resolves that packages providing a .desktop file 
shall not also provide a menu file for the same application", it took a 
steering stance on where it saw the project going, and gave a strong pushback 
to the volunteers working on providing a good "menu" experience.

As long as the TC is this "steering group", it will be as progressive as its 
members, and I make no mystery of my fondness of a "progressive" TC on 
steering questions [4]. But if the project wants more conservative (or just a 
different) steering, then we should be discussing about how to make this 
hypothetical "steering group" more aligned with the aspirations of the project 
at 

Re: Automatic downloading of non-free software by stuff in main

[Didier 'OdyX' Raboud]

Le jeudi, 30 novembre 2017, 18.54:32 h CET Ian Jackson a écrit :
> [1] The GR would require a 2:3 supermajority because the TC abandoned
> my efforts to reform the bugs in its constitutional foundations, when
> I left the TC.

These don't need to be carried by the TC. It's "nice" if the TC kept in the 
loop though. 

OdyX

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Didier 'OdyX' Raboud]

Le lundi, 7 août 2017, 09.40:22 h EDT Russ Allbery a écrit :
> Daniel Kahn Gillmor  writes:
> > debian-policy should encourage verification of upstream cryptographic
> > signatures.

Yes.

> diff --git a/policy.xml b/policy.xml
> index 6086901..c14d9b4 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -2556,11 +2556,28 @@ endif
> 
>
>  This is an optional, recommended configuration file for the
> -uscan utility which defines how to
> +uscan utility which defines how to
>  automatically scan ftp or http sites for newly available updates
>  of the package.  This is used Debian QA tools to help with quality

While were at patching this, this sentence should read:
> This is used _by_ Debian QA tools …
or
> This is used _by some_ Debian QA tools…

Other than that, seconded!

Cheers,
OdyX

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Didier 'OdyX' Raboud]

Le jeudi, 3 août 2017, 08.53:09 h CEST Didier 'OdyX' Raboud a écrit :
> Le mardi, 1 août 2017, 11.01:10 h CEST Sean Whitton a écrit :
> > On Thu, Sep 29, 2016 at 02:55:31PM -0400, Sam Hartman wrote:
> > > We also approved the decision that packages should not include both a
> > > menu file and a desktop file.
> > 
> > For reference, Policy currently says that packages should include a
> > desktop file, and may also include a menu file for the sake of old
> > window managers.
> > > The action to draft language for that has stalled in the policy
> > > process.
> > 
> > Is there a policy bug that got stalled?  If not, maybe this bug should
> > just be reassigned to policy?

I now gathered some old memories and remembered that there was indeed a bug 
about this that got stalled: #707851 (which was the TC bug). See from message 
#475 (September 2015), where I tried to push a wording quite similar to yours 
to Policy:

> +Applications that are registred in the desktop menu shall not also
> +provide a Debian menu file for the same application.

So https://lists.debian.org/debian-policy/2015/09/msg00024.html is the start 
of the thread that stalled.

I read the arguments back then as critics against the TC decision itself, not 
discussions about the wording. My argument back then (and it has not changed) 
is that now that the TC decision is made, it should find it's way into the 
Policy.

So… I'm fine with your wording, but thought it'd be useful to point at the 
previous discussion about this very subject.

Cheers,
OdyX

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

Bug#850646: [copyright-format] Allow https version of Format URI

[Didier 'OdyX' Raboud]

Le dimanche, 8 janvier 2017, 12.02:38 h CET Russ Allbery a écrit :
> Here's an updated patch that also fixes the other examples.

Seconded.

-- 
Cheers,
OdyX

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

Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs

[Didier 'OdyX' Raboud]

Le lundi, 24 octobre 2016, 07.23:30 h CET Colin Watson a écrit :
> Control: tag -1 patch
> 
> On Sun, Oct 23, 2016 at 08:00:23PM -0700, Sean Whitton wrote:
> > Policy section "Permissions and owners" probably shouldn't recommend
> > contacting the base-passwd maintainer when selecting a username for a
> > dynamically-allocated UID created by a postinst maintscript.  It should
> > continue to recommend contacting the base-passwd maintainer when the
> > postinst script needs to create a static UID.
> 
> I (obviously) agree.  How about this patch?  I'm seeking seconds for
> this proposal.
> 
> diff --git a/policy.sgml b/policy.sgml
> index 9cd182b..ab4f736 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9610,9 +9610,7 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
> that a dynamically allocated id can be used.  In this case
> you should choose an appropriate user or group name,
> discussing this on debian-devel and checking
> -   with the  -   they do not wish you to use a statically allocated id
> -   instead.  When this has been checked you must arrange for
> +   that it is unique.  When this has been checked you must arrange for
> your package to create the user or group if necessary using
> adduser in the preinst or
> postinst script (again, the latter is to be

Seconded.

-- 
Cheers,
OdyX

Bug#806993: ftp-master-mirror is not on ries.d.o anymore

[Didier 'OdyX' Raboud]

Package: developers-reference
Version: 3.4.16
Severity: important
Tags: patch

The devref currently points to ries.d.o for the ftp-master-mirror, that is
currently on coccia. According to db.debian.org, the FTP-Masters have decided
to allocate it an alias: mirror.ftp-master.debian.org.

I've attached a patch to fix that.

Cheers,

OdyX
>From c633291e4d8ad472f1f6a04749cb41f41b284621 Mon Sep 17 00:00:00 2001
From: Didier Raboud 
Date: Thu, 3 Dec 2015 20:53:26 +0100
Subject: [PATCH] Replace ries.d.o with mirror.ftp-master.debian.org alias for
 the developer accessible archive copy

---
 common.ent | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common.ent b/common.ent
index a1ec2b0..62b93d8 100644
--- a/common.ent
+++ b/common.ent
@@ -51,7 +51,7 @@
 
 
 
-
+
 
 
 https:///doc/debian-policy/;>
-- 
2.6.2

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit :
> But _forbidding_ maintainers who want to from shipping a second file,
> if that somehow makes the experience of menu users better than what
> the fdo menu would have given them? Sorry, but that seems petty and
> silly.

For context, the exact phrasing of the TC decision is "packages 
providing a .desktop file shall not also provide a menu file for the 
same application."

This translates to "this situation constitutes a bug", but doesn't 
specify an explicit patch for the Debian Policy (aka doesn't explicitly 
lay down the severity of the bug). I'd argue that in the absence of a 
new Debian Policy version incorporating the TC decision, such situations 
would be 'serious' bugs. Can we work towards ironing an adequate 
wording? 

> I don't think I'll encounter the issue, seen as none of my packages
> ship any menu entry, let alone a .desktop file, today. But yeah, it's
> something I think I'll blatantly ignore if/when the time comes.

Threatening to "blatantly ignore" the Debian Policy isn't terribly 
helpful.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2015, 07.52:55 Sam Hartman a écrit :
> >> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit:
> >> But _forbidding_ maintainers who want to from shipping a second
> >> file, if that somehow makes the experience of menu users better
> >> than what the fdo menu would have given them? Sorry, but that
> >> seems petty and silly.
> 
> Didier> For context, the exact phrasing of the TC decision is
> Didier> "packages providing a .desktop file shall not also provide a
> Didier> menu file for the same application."
> 
> Didier> This translates to "this situation constitutes a bug", but
> Didier> doesn't specify an explicit patch for the Debian Policy (aka
> Didier> doesn't explicitly lay down the severity of the bug). I'd
> Didier> argue that in the absence of a new Debian Policy version
> Didier> incorporating the TC decision, such situations would be
> Didier> 'serious' bugs. Can we work towards ironing an adequate
> Didier> wording?
> 
> No, i don't think so at all.
> It's quite clear from the TC minutes that serious was not intended,
> and there's no evidence that shall from the TC means the same
> thing as must in the policy.

I'm puzzled by your successive positions about this question in this bug 
log, really. But fair enough, I understand you're referring to Keith's 
<86si6udah7@hiro.keithp.com> message:
> we agreed that that this decision would not cause them to be
> classified as RC-buggy for the stretch release.

… although I cannot remember (or find logs for) this precise discussion.

Anyway, I'm hereby retracting my assumption of bug severities to be 
applied on packages shipping applications with both XDG and trad menu 
entries. Let's get back to finding a proper wording implementing the TC 
decision in Policy, please.

OdyX

Re: Next update of the Policy ?

[Didier 'OdyX' Raboud]

Le dimanche, 4 octobre 2015, 00.07:02 Bill Allombert a écrit :
> On Sat, Oct 03, 2015 at 10:55:38AM +0200, Didier 'OdyX' Raboud wrote:
> > For the avoidance of any doubt, I agree that committing the diff was
> > premature, although I assume it wasn't done in bad faith. Sorry for
> > the situation,I should have made clearer that my proposal was a
> > discussion starter, only.
> 
> You are not at cause.
>
> Charles is not a policy editor (…)

I don't see how this /ad hominem/ charge is in anyway useful for the 
Policy process, sorry. Especially so when written _after_ Charles 
already announced he would back off for a year.

OdyX

Re: Next update of the Policy ?

[Didier 'OdyX' Raboud]

Charles & Steve,

Le vendredi, 2 octobre 2015, 19.42:53 Steve Langasek a écrit :
> On Sat, Oct 03, 2015 at 11:23:02AM +0900, Charles Plessy wrote:
> > to fully implement the TC's decision, I think that it would be best
> > to upload the updated Policy.
> 
> I see that you have committed Didier's proposed text to the git
> repository.
> 
> This is highly inappropriate.  The Technical Committee has passed a
> resolution that provides general technical guidance to the project. 
> That does not mean that the TC has approved any *particular* policy
> language, or that the normal policy process may be bypassed in
> deciding the policy language.

For the avoidance of any doubt, I agree that committing the diff was 
premature, although I assume it wasn't done in bad faith. Sorry for the 
situation,I should have made clearer that my proposal was a discussion 
starter, only.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 22 septembre 2015, 13.47:31 Charles Plessy a écrit :
> Le Mon, Sep 21, 2015 at 11:27:53AM -0400, Sam Hartman a écrit :
> > Hi.  I've been debating how to respond to the shall vs must thing. 
> > The short answer is that there are reasons why you might prefer
> > shall, but I find that I'd rather say "must is good enough," than
> > try and come up with an articulate presentation of the energy which
> > would conclude by saying that if must still seemed like the right
> > choice go with it.
> > 
> > So,  I'm fine with s/shall/must.
> 
> Thanks Sam,
> 
> the word "shall" appears only once in the Policy (quoted below), so I
> think that avoiding it is consistent with the Policy's style.
> 
>If the package is architecture: any, then
>the shared library compilation and linking flags must have
>-fPIC, or the package shall not build on some of
>the supported architectures
> 
> I still have commit priviledges on the Policy's Git repository on
> Alioth, so if the Policy Editors are busy, I can implement the TC's
> decision.

For what I'm concerned, at least for the "cherry-picking" part of the TC 
decision, please go ahead.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 29 septembre 2015, 14.34:35 Guillem Jover a écrit :
> Which contains the requirements for the XDG entry, one of those being
> the icon. If the upstream part does not contain a suitable icon, then
> removing the XDG entry and any relevant icon shipped in the debian/
> directory makes the application obviously non-compliant.
> 
> > Applications "should" be registered in the FreeDesktop menu if that
> > makes sense.
> 
> For a menu supporter who packages applications for their own use,
> I'd presume it would be obvious that making them inaccessible from
> their non-XDG compliant environment makes no sense.

Two points here:
* so far, both in the Policy and during the TC discussion, these "menu 
supporters" have been _mostly_ hypothetical;
* these entries would be absent as long as the "menu program" fail to 
properly use the 'XDG menu' entries, that's the point of the TC 
decision.

> > > So we might end up with packages by menu supporters removing
> > > .desktop files, and packages from XDG supporters removing .menu
> > > files. And users of either format caught inbetween.
> > 
> > The TC decision is saying "XDG menu is now the source, it should be
> > read by 'trad menu' programs,
> 
> W/o anyone to implement this in the menu programs, this is just
> wishful thinking, and might leave big chunks of our users with
> inaccessible applications. On either side of the fence.

Yes. That's exactly the point: the work to keep the 'trad menu' relevant 
is to be made by those who care about it.

> > In the light of the TC decision, I would personally consider a
> > package dropping an XDG desktop entry in favor of a menu entry
> > buggy (although there will certainly be cases debatable cases).
> 
> To me this is the equivalent of a package with suitable applications
> for the XDG menu, not currently shipping an XDG entry. So now you
> declare all those insta buggy as well.

Not anymore buggy than with the previous "trad menu" policy (§9.6 in 
3.9.6), for what is worth: it said:
> All packages that provide applications that need not be passed any
> special command line arguments for normal operation should register a
> menu entry for those applications.

Large parts of Debian have been buggy under this text, for a long time.

> > "The TC" is not going to engage in detailed design work (or
> > implementation work, for what is worth), although any of its members
> > could (but I don't see this happening).
> 
> Exactly my point. This is the equivalent of mandating that the Debian
> Future Team should design and implement an FTL engine, where of course
> the TC has not engaged in any design work. This to me fails §6.3.5.

I obviously disagree, but invite you to challenge this decision in 
forums other than the debian-policy list.

Second, the TC has not mandated any work to any particular team: it 
changed the ecosystem in which the 'trad menu' programs evolve. Mind 
you, program ecosystems evolve all the time; 'trad menu's was relying on 
the Debian Policy mandating entries for all applications "that need not 
be passed any special command line arguments", the TC decision drops 
that requirement.

--
OdyX

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

Bug#792853: debian-policy: please disallow colons in upstream_version

[Didier 'OdyX' Raboud]

Le mardi, 29 septembre 2015, 21.09:02 Charles Plessy a écrit :
> Le Tue, Sep 29, 2015 at 01:40:34PM +0200, Didier 'OdyX' Raboud a écrit 
:
> > Le samedi, 26 septembre 2015, 15.03:09 Charles Plessy a écrit :
> > > Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a écrit :
> > > > * Charles Plessy <ple...@debian.org>, 2015-09-24, 21:53:
> > > > >-: ~ (full stop, plus, hyphen,
> > > > >colon,
> > > > >+: ~ (full stop, plus, hyphen,
> > > > 
> > > > Remove :, too.
> > > 
> > > Thanks for the proofreading.
> > > 
> > > With this correciton, are there people seconding the proposed
> > > change ?> 
> > Seconded.
> 
> Thanks,
> 
> here is a patch for the Policy editors.

This patch doesn't have Jakub's suggestion to drop : too.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Hi Charles,

I noticed you committed this typo of mine to the git repository, sorry 
for that:

Le jeudi, 17 septembre 2015, 15.25:54 Didier 'OdyX' Raboud a écrit :
> +  Applications that are registred in the desktop menu shall
---^

Cheers,
OdyX

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

Bug#792853: debian-policy: please disallow colons in upstream_version

[Didier 'OdyX' Raboud]

Le samedi, 26 septembre 2015, 15.03:09 Charles Plessy a écrit :
> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a écrit :
> > * Charles Plessy , 2015-09-24, 21:53:
> > >-: ~ (full stop, plus, hyphen, colon,
> > >+: ~ (full stop, plus, hyphen,
> > 
> > Remove :, too.
> 
> Thanks for the proofreading.
> 
> With this correciton, are there people seconding the proposed change ?

Seconded.

Cheers,
OdyX

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

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> Wow, this is such terrible policy… So we have supporters of the XDG
> format, and supporters of the menu format. Some of those would and
> have accepted files of their non-preferred format in their packages,
> some have outright refused them. But now they have to choose between
> one of them, because they can no longer ship both.

One of the points of the TC decision is precisely to avoid a "free 
choice" between the two formats. The first point of that decision is to 
adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy, 
which contains:
> Packages shipping applications that comply with minimal requirements
> described below for integration with desktop environments should
> register these applications in the desktop menu, (…)

Applications "should" be registered in the FreeDesktop menu if that 
makes sense. The second point of the TC decision (which phrasing to be 
committed in the Debian Policy we're currently discussing) is to forbid 
applications that do provide XDG menu entries to _also_ provide "trad 
menu" entries.

> So we might end up with packages by menu supporters removing .desktop
> files, and packages from XDG supporters removing .menu files. And
> users of either format caught inbetween.

The TC decision is saying "XDG menu is now the source, it should be read 
by 'trad menu' programs, and _can_ be completed for the range of 
applications that don't make sense in the XDG menu, but do make sense in 
the 'trad menu'". Like it or not, this is decided, and we're "only" 
discussing how this should take form in the Debian Policy.

In the light of the TC decision, I would personally consider a package 
dropping an XDG desktop entry in favor of a menu entry buggy (although 
there will certainly be cases debatable cases).

> Also is the TC going to implement the changes in the "menu programs"
> to support the XDG format? Because I don't see the ruling to be very
> motivating for the menu supporters.

"The TC" is not going to engage in detailed design work (or 
implementation work, for what is worth), although any of its members 
could (but I don't see this happening).

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Control: severity -1 important

Hi all,

As you have certainly seen on debian-devel-announce [0], the Technical
Committee has ruled on the question of Debian Menu Systems, and the
technical decision should now find a form within the Debian Policy.

First, the commit designed in the aforementionned decision [1] must be
cherry-picked in the Debian Policy repository by whoever has the rights
to do so, ideally by one of the Policy editors.

Second, we should discuss an appropriate phrasing for putting the
points 2 and 3 of the TC decision into the Debian Policy:

>2. In addition to those changes, the Technical Committee resolves
>   that packages providing a .desktop file shall not also provide a
>   menu file for the same application.
> 
>3. We further resolve that "menu programs" should not depend on the
>   Debian Menu System and should instead rely on .desktop file
>   contents for constructing a list of applications to present to
>   the user.

I'm hereby proposing the following diff for point 2, as a discussion
starter:

diff --git a/policy.sgml b/policy.sgml
index ee1e9f4..83e4057 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8192,14 +8192,18 @@ Reloading description configuration...done.

 
 
- Packages can, to be compatible with Debian additions to some window
- managers that do not support the FreeDesktop standard, also provide a
+ Applications that are not registered in the desktop menu can 
optionally provide a
  Debian menu file, following the Debian menu policy,
  which can be found in the menu-policy files in the
  debian-policy package.  It is also available from the Debian
  web mirrors at http://www.debian.org/doc/packaging-manuals/menu-policy/;>.

+
+
+  Applications that are registred in the desktop menu shall not also
+  provide a Debian menu file for the same application.
+
   
 
   

Cheers,
OdyX

[0] 
https://lists.debian.org/msgid-search/20150904033414.gd3...@qor.donarmstring.com
[1] 
https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

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

Bug#796442: §5.5 Uploads to suites other than unstable/experimental should use codenames, not suites

[Didier 'OdyX' Raboud]

Package: developers-reference
Version: 3.4.15
Severity: important
Tags: patch

As I understand the current Release Team practices (in X-Debbugs-CC), uploads
to non-unstable/experimental suites should nowadays rather use the codenames
(wheezy, wheezy-proposed-updates, wheezy-security or wheezy-lts) instead of
suites (oldstable, oldstable-proposed-updates, oldstable-security or
oldstable-lts). Although both styles work, using the codenames avoids
race-conditions in times around new stable releases, and are less confusing.

This could be a possible diff:

--- devref.orig.txt 2015-08-21 22:49:46.985614431 +0200
+++ devref.new.txt  2015-08-21 22:58:15.226984105 +0200
@@ -2209,9 +2209,10 @@
 from the first line of the debian/changelog file and places it in
 the Distribution field of the .changes file.
 
-There are several possible values for this field: stable,
-    unstable, testing-proposed-updates and experimental. Normally,
-packages are uploaded into unstable.
+Packages are normally uploaded into unstable. Uploads to unstable or
+experimental should use these suite names in the changelog entry;
+uploads for other supported suites should use the suite codenames,
+as they avoid any ambiguity.
 
 Actually, there are other possible distributions: codename
     -security, but read Section 5.8.5, “Handling security-related

Cheers, OdyX

Re: Updating the Policy Editors delegation

[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.