Re: Next update of the Policy ?

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> On Sun, Oct 04, 2015 at 12:07:02AM +0200, Bill Allombert wrote:
>> The GIT repository is only a tool for the policy editors. Due to
>> the decentralized nature of GIT, anybody can clone it anyway and
>> send a pull request.  Pushing to it directly is uselessly
>> interfering with the policy editors job.

Bill> Hello,

Bill> To allow everybody to forget about this infortunate accident
Bill> and let us continue to maintain the policy, I have reset the
Bill> master branch to the last commit before Charles intervention,
Bill> which is 282bd883. If you have already pulled Charles changes,
Bill> please reset your master branch.

When will you be merging in  ba679bff as adopted into Debian policy by
 the TC decision?


--Sam

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

[Wouter Verhelst]

On Tue, Sep 29, 2015 at 11:39:47AM +0200, Didier 'OdyX' Raboud wrote:
> 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, I'm with Guillem on this one.

Saying that the FreeDesktop menu should be the default and "source"
format, I wholeheartedly support that choice. Making it clear that not
shipping a .menu file is not a bug, and that it is a bug (not
necessarily RC, but still) for a window manager to not look at the fdo
menu? Sure, great policy.

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.

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.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

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

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> So, I'm with Guillem on this one.


Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.

OK.
Then why don't you build consensus behind a patch to do that?
The TC's decision can be changed by the normal policy process.
If you can get people to agree with a proposal that permits both
.desktop and .menu files then you can replace the TC decision.

For myself, I think that forcing a transition to .desktop will create a
longer Debian long-term.  I believe that the TC's approach provides a
useful push for that in this situation.
I realize that it is a fairly forceful approach and it's not something
that Debian does often.
It seems to be a case where the broader community might disagree with
the TC and if that's the case, then I would be happy with that result.

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

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:

Didier> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit
Didier> :
>> 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.

When I read the message I feel a great frustration because I'm hoping
that we can work with respect.  It sounds like you are trying to build
up an interpretation that was never intended and create a bad
consequence for the status quo to drive resolution.
I do not support that.  I fully realize that it's easy to assume
motivations different than intended.

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 ?

[Bill Allombert]

On Sun, Oct 04, 2015 at 12:07:02AM +0200, Bill Allombert wrote:
> The GIT repository is only a tool for the policy editors. Due to the
> decentralized nature of GIT, anybody can clone it anyway and send a pull 
> request.
> Pushing to it directly is uselessly interfering with the policy editors job.

Hello,

To allow everybody to forget about this infortunate accident and let us continue
to maintain the policy, I have reset the master branch to the last commit
before Charles intervention, which is 282bd883. If you have already pulled
Charles changes, please reset your master branch.

However I have created a branch master-charles with Charles changes, so that
they are not lost.

Sorry for the trouble,
-- 
Bill. 

Imagine a large red swirl here. 

Processed: limit source to debian-policy, tagging 799779

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #debian-policy (3.9.7.0) unstable; urgency=low
> #
> #  * autopkgtest: new document containing the specification of automatic,
> #as-installed (AKA autopkgtest, or DEP-8) package tests
> #Closes: #799779
> #
> limit source debian-policy
Limiting to bugs with field 'source' containing at least one of 'debian-policy'
Limit currently set to 'source':'debian-policy'

> tags 799779 + pending
Bug #799779 [debian-policy] integrate autopkgtest/DEP8 specification into 
debian-policy
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
799779: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799779
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems