Re: CTTE requesting questions for DebConf20 BoF

[Charles Plessy]

Le Sun, Jul 26, 2020 at 01:37:10PM -0700, Sean Whitton a écrit :
> 
> **Proposal 3**: Modify the Constitution to allow the TC to do design
> work in the form of proposals. These proposals wouldn't override
> developers or tell individual maintainers what to do, but rather should
> guide the project towards a technical goal.

Hi Sean and everybody,

to some extent, the TC can already do some design work.  For instance,
in the past I wanted to describe the FreeDesktop menu entries in the
Policy, got in conflict with another Policy maintainer on that topic,
and the final result was the TC ruling about the Debian menu, which is
something I never asked for.

I think that your proposal is an excellent idea that would give a
clearar separation between design work and conflict resolution.

Have a nice day,

Charles

-- 
Charles Plessy  Akano, Uruma, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Charles Plessy]

Le Mon, Aug 31, 2015 at 01:57:21PM -0700, Keith Packard a écrit :
> Sam Hartman  writes:
> 
> > OK.
> > I'd really appreciate hearing from anyone now who needs more time before
> > a CFV.
> 
> I'd also love to hear back from Charles about the updated D proposal,
> and whether that helps him understand what it means.

Hi Keith and everybody,

I think that proposal D', with or without Sam's additions, makes the ballot
much more consistent than before.

Just in case it escaped your mailbox, I also wrote a slightly longer answer
yesterday.

  

Have a nice day, and thanks for your efforts.

-- 
Charles

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Charles Plessy]

Le Sun, Aug 30, 2015 at 10:01:27PM -0700, Keith Packard a écrit :
> 
> Thinking about this tonight, I've rewritten option D as AB + patch.
 
> OPTION D':
> 
> Using its power under §6.1.1 to decide on any matter of technical
> policy, and its power under §6.1.5 to offer advice:
> 
>1. The Technical Committee adopts the changes proposed by Charles
>   Plessy in ba679bff[1].
> 
>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.
> 
>4. We advise the maintainers of the 'menu' package to update that
>   package to reflect this increased focus on .desktop files by
>   modifying the 'menu' package to use .desktop files for the
>   source of menu information in addition to menu files.
> 
>5. Discussion of the precise relationship between menu file
>   section/hints values and .desktop file Categories values may be
>   defined within the Debian Menu sub-policy and Debian Menu
>   System.
> 
>6. Further modifications to the menu policy are allowed using the
>   normal policy modification process.
> 
> [1]: 
> http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Thanks a lot, Keith, I think that this is much clearer and integrates very well
in the ballot.

Minor points follow, but I am happy with the current ballot and do not want
to introduce further delays.

 - When I asked for acknowledgement, I was reffering not to the Policy patch,
   but to the wiki page from 2008 
<https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries>.
   However, if option D' does not contain anymore the transition plan of option 
D,
   there is no need to mention the wiki page anymore.

 - Since the only difference between options A and B is a statement on the
   Policy process that is orthogonal to the technical decision on the menu, I
   would recommend to just drop option B.  This is in line with the fact that
   option D' here is following A.1 and not B.1. 

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Charles Plessy]

Le Mon, Aug 17, 2015 at 06:14:45PM +0200, Didier 'OdyX' Raboud a écrit :
 Hi Charles, and thanks for your feedback,

Thanks as well for your prompt answer :)  Here are a few point-to-point
comments.  Altogether, I would happily support option D if it were further
amended.

 the last sentence of D1, put in force 
 using §6.1.1 (decide on any matter of technical policy): Applications 
 providing a .desktop file should not provide a Debian menu file. This 
 will allow maintainers that _do_ provide .desktop files to stop 
 providing .menu files as well.

Indeed, I have overlooked that important part.  Sorry for this.
 
 With D1 in place, I expect .menu files to 
 start disappearing from the archive at a good pace; it will become 
 somewhat urgent for those relying on the menu system to work towards 
 having this .desktop-to-menu translation infrastructure in place.

An alternative would be to develop support for the FreeDesktop menu on those
platforms that only have the Debian menu at the moment.

Since option D is calling for volunteer work, which may be quite unusual for
the TC, I think that it would be important that it either provides alternatives
like the one above, or explain briefly why they were not retained in the final
resolution.
 
  https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
 
 I think it is quite reasonable to assume that Keith's proposal is a 
 derivative of that proposal.

Thanks.  I would appreciate if it would be acknowledged, I am a bit academic by
training...

 The TC is currently trying to decide whether to decide on the conflict 
 (AB vs C) or to decide on the 'menu' matter of technical policy (D).

In my impression, it is not a good thing to conflate two different kind of
decisions in the same vote.  This said, the current portfolio of options is a
good ground for focusing on the technical aspects.

C: Status quo reaffirming the wording of the Policy and the importance of
   the Debian Menu (needed even for the Python interpreter, etc).

Z: Status quo by inaction.

AB: Softening the requirement of the Debian Menu.

D: Migration to the FreeDesktop format, and therefore disparition of the Debian
   Menu if nobody works on this migration.

(By the way, I am not sure how to interpret the difference between A and B.)

I have invested a lot of time on AB as I was looking for a compromise that
would satisfy broady, but as I wrote more recently, I also do not mind a more
radical outcome.  I would support option D it if we resolve the the point
below.

 From what I understand of your opposition, you're afraid that further 
 discussions around softening the all packages that provide applications 
 that need not be passed any special command line arguments for normal 
 operation should provide a FreeDesktop .desktop file entry for those 
 application part would be met with unresolvable opposition from Bill, 
 right? What about the following formulation then (not yet entirely 
 convinced, but I hope that's a step forward)?
 
1. The Technical Committee resolves that applications providing a
   .desktop file should not provide a Debian menu file.

This is the first half of solving the problem.  The second would be to add that
the should requirement of the Policy's section 9.6, paragraph 2, is changed
to may.

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Charles Plessy]

Le Sun, Aug 16, 2015 at 05:54:50PM +0200, Didier 'OdyX' Raboud a écrit :
 
3. We recommend that the maintainers of the 'menu' package update
   that package to reflect this increased focus on .desktop files
   by modifying the 'menu' package to use .desktop files for the
   source of menu information in addition to menu files.

Hi Didier and everybody,

I think that option D has two fundamental flaws and I would like to recommend
the TC against voting for it.

* First, if it is voted, nothing will happen.

If the TC adopts option D, and if the maintainer (no plural) of the 'menu'
package decides to not follow point 3's recommendation, what will be the
practical difference between option D and option Z ?  I voiced this concern in
2014 (741573#450), but got no answer.  Who do you expect to do the work ?

The reason I ask is that option D carries nothing new.  In 2008, we already
had a discussion which outcome was very similar to what is proposed in option D.

https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

Nothing happened in 5 years, in my opinion because a) the Debian menu system
is written in C, which does not help for attracting propositions of patches,
and b) its maintainer is obviously hostile to change.

* Second, it does not solve the problem that I sumbitted to the TC.

See in particular Josselin's objection in 741573#405 and Keith's answer:

Josselin:

   One of the problems I have with your proposal, compared to Charles’ original
   patch, is that it encourages maintainers of hundreds of (IMHO useless) menu
   files to port them to the desktop format.

Keith:

Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:

  All packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

Option D exactly brings use back to the original problem, without solving it !
Please remember that the title of the bug where the dispute stems is : soften
the wording recommending menu files.  In that sense, the format of the menu
files does not matter.  What Bill opposes with his trench war and delay tactics
is the modification of §9.6 above.  Option D does not contain such a change.

What will happen if option D is voted ?  Nothing.  In 2008, the popcon vote
score of the menu package was around 35 %, in 2014 around 25 % and now in 2015
it is around 15 %.  And much of it may be just because of its dpkg trigger.  If
the TC votes option D, I will be disappointed but rest assured that the issue
will not come back to the TC later again: the Debian menu will dissapear
eventually by itself.

The problem here is our inability to face the facts and accept to change the
Policy to fit the reality.  This is what I asked the TC for.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Thu, Jul 23, 2015 at 02:12:31PM +0200, Bill Allombert a écrit :
 
 This is not the case. I made my position clear the first time in the bug log,
 but one year later Charles decided to restart the discussion while ignoring 
 all
 that was previously said. That made me angry and I have a policy not to post
 when I am angry.
 
 Charles write with the undertone that his position will carry the day and that
 naysayer are a minority, which I find displeasing, especially when aiming for
 consensus, going as far as 'apologizing' to peope wanting to continue to 
 support
 Debian menu.

Bill, you are the only person complaining, and your position is not clear.

The original request is to soften the wording recommending menu files and
everybody except you agrees to do so.

The wording has been made without your input, because you did not participate
constructively to that part of the discussion.  You only were throwing in
vague arguments and taking other people as strawmen.

I made efforts to keep the wording mild, but I think that it was an error.
From your attiude as the lead person behind the Debian Menu, it is clear that
it has no future.  For one decade, you have taken no leadership to build this
future.  As a consequence, I think that the next step is to plan its
replacement and deprecation.  Maybe the TC will come to this conclusion.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015072313.gc16...@falafel.plessy.net

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a écrit :
 
 Bill, in his role of policy editor said that he believed there was not a
 consensus.

Hi Sam,

I think that what you wrote does not reflect what happened:

 - Russ gave me the green light for committing the changes, see
   https://lists.debian.org/debian-policy/2014/02/msg00068.html.  Only Policy
   Editors can decide that a change will be committed, thus it is my 
understanding
   that Russ, as a Policy Editor, judged that there was consensus.

 - Without consulting with the other Policy Editors, Bill reverted the commit.
   This solo action was done out of the usual process for seeking consensus
   before changing the Policy.

 A lot of my experience with consensus process is in the IETF.  There, if
 you're in a position to judge consensus, you have an obligation to help
 try and build the consensus when you judge that there is not consensus.
 If you're in a position to judge consensus, you have an obligation to
 lead the discussion, to focus on areas of disagreement, and to see if
 your consensus call is correct.  There's an expectation that when you
 call a lack of consensus, getting to consensus is going to be a
 priority, and you're going to put in significant time to help.
 
 Should some or all of the above be part of what we expect from policy
 editors?

I totally share this point of view.  (This is why after leading the release of
the Policy version 3.9.5.0, seeing that I would not have time to do the same
within a year or two, I quitted as a Policy Editor).

 On another axis of the discussion, what's the appeals process?

The only appeal I would see would be through the DPL, since he appoints and
replaces the Policy Editors, who are DPL delegates.

Have a nice Sunday,

PS: I will be on business trip in Trieste for one week.

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719123950.gb4...@falafel.plessy.net

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a écrit :
  Bill == Bill Allombert ballo...@debian.org writes:
 
 Bill I want to point out that I have split the menu policy changes
 Bill in 3 parts, so that the less controversial part could be
 Bill decided separately, see #742532.  However nobody was
 Bill interested in seconding this. So I am let to believe there is
 Bill no actual consensus on this.
 
 I agree that there doesn't seem to be consensus on your proposed split.

Hello everybody,

I am not willing to enter discussions on whether I agree on subsets of a
proposal that I already approved as a whole in totality.  This is a waste of
time (that reminds me Zenon's paradox).

Also, the question is not whether the FreeDesktop menu should be described in
the Policy or not, or how to split the proposal in 3, 4 or 42 parts.  It is not
even on whether the Debian menu should be a must or a should, because for
that as well, we got a rough consensus, where at the end of the process there
was only a single person opposing the change.  Neither it is about re-starting
a search for people disagreeing (or shall I restart a GR on systemd ?).  The
question is whether a single individual can engage in confrontational commit
wars to block changes in Debian.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719003130.gc15...@falafel.plessy.net

Bug#741573: Investigation of the bug log

[Charles Plessy]

Le Tue, Jun 23, 2015 at 04:59:07PM -0400, Sam Hartman a écrit :
 
 If you seconded the proposal, I'd like to confirm that as part of your
 second, you believed that there was rough consensus and that objections
 that were raised had been addressed.  That is, please confirm that you
 evaluated not just the quality of the proposal, but also evaluated the
 discussion.

Hi Sam,

I confirm that when seconding the proposal, it was my assessemnt that a rough
consensus has been reached.  As a former Policy Editor, I was well aware that
seconding is not merly a voting process.

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150624231433.ga23...@falafel.plessy.net

Bug#741573: Requesting input on TC deliberations about menu system and policy

[Charles Plessy]

[I think that what follows is entirely redundant with what I wrote earlier.]

Le Mon, Mar 30, 2015 at 08:32:58PM -0400, Sam Hartman a écrit :
 
 Steve  claimed that the policy process is not a rough consensus process
 and that the fact that Bill objected  in-and-of-itself might be
 sufficient to argue that there was not consensus.
 The process.txt document dated Spetember 14, 2014 does not support
 Steve's claim.  I have not read previous versions of that document, and
 I don't know which version of the process the TC should look at here.

Hi Sam,

thanks for your efforts in resolving this conflict.

After one year of discussion and negociation, following the policy change
process, a consensus was found, with nobody standing up against it.  A couple
of weeks later, Bill abused his commit privileges and reverted the change.  I
think that this is clearly unacceptable, and I hope that the change on which
everybody worked on and agreed will be restored without further discussion.

If the TC insits on discussing, then the next question is what to discuss.  And
then you will realise that Bill's objections are still not clear as of today.
Since Bill makes no effort to discuss, I think that the discussion should stop
with the rejection of his objections.

In the end, what is at a stake here is not the menu systems.  The Debian menu
system is not a default anymore, and after the release we will see its
installation rate erode, and its usage to continue to fade away.  Blocking the
policy change has no effect, because already a large number of package
maintainers disregard that in theory, it is a must to have a menu entry for
every interactive program in Debian.

So what is at a stake here, is whether the Policy reflects the current
consensual and unchallenged practice, or whether it is lagging on real facts by
a couple for years or more.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150331102027.gc30...@falafel.plessy.net

Bug#741573: Two menu systems

[Charles Plessy]

Dear TC,

I would like to react to Ian's message, that uses words like deliberate
dismantling that can be interpreted as if the misbehaviour is on my side, and
will add a remark on the fact that Policy maintainers have no veto in
contrary to what seemed implied in November's TC meeting on IRC.

First, there is no dismantling of the Debian menu in the Policy.  Ian calls
this menu comprehensive, but the reality is that its coverage is patchy, in
sharp contrast with the must directive in the Policy.  The patch applied
changed this to a should, which is a strong statement that is ground for
overriding maintainers refusing patches with no reason.  This adjustement of
the Policy to the current practice was the core answer to the original
requirement in #707851.

On top of this change I wanted to take the opportunity to brush up the Policy
by describing how to use FreeDesktop menu entries in Debian.  Very
unfortunately, this gave the impression that one menu system replaces the
other, but in practice it is two parallel changes.  This is why I am asking the
TC to refrain from refactoring that part of our work: it has full consensus,
and to be honest, I would feel it a big slap in my face (in the sense that it
would call for me reconsider if my contribution is really welcome) if the TC
would bypass the Policy change process to modify the changes related to the
FreeDesktop menu.

Ian's message goes in length on obstructive behaviours.  I disagree with such
behaviours and I think that the TC should override maintainers who deliberately
block the work of others for tactical reasons.  The obstruction discussed here
is the one of a Policy editor who ignored the Policy changes process and
engaged in an blocking strategy by withdrawing the discussion and then
reverting the consensus-driven changes unilaterally.  

In the Policy changes process there is no vote and there is no veto.  Bill had
ample time to make his points when the discussion was opened.  See through the
BTS entry: I took all the time needed - more than eight months ! - to address
people's reactions and seek consensus.  The consensus was assessed by a Policy
editor, which is the final point of the process.  Bill's behaviour turns the
whole discussion into a waste of time, and leaves the Policy in a state that
does not reflect the reality.  Far from increasing the coverage of the Debian
menu systems, Bills commit reversal undermines the value of Debian's policy
manual and sends the message that the personal opinion of Policy editors has
precedence on consensus (and the *work* that it represents to create that
consensus).

For this reason, sorry to repeat myself, I am asking the TC to please rule on
the question that I raised: should Bill's commit reversal be overriden ?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141223031101.GA14049@aqwa.igloo

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

[Charles Plessy]

Le Mon, Nov 17, 2014 at 11:58:41AM +0100, Lucas Nussbaum a écrit :
 
 Specifically, I would like to ask Debian Developers to contribute
 (positively) to TC discussions when relevant, in order to help the TC
 get a complete understanding of the issues, their consequences, and
 possible resolutions paths. I was disappointed to see that only a
 handful of DDs (outside of TC members) took part in the recent technical
 discussions. Every DD should really feel welcomed to act like a
 (non-voting) TC member.
 
 I would also like to ask the TC to provide a bit more time for public
 discussions (during the technical discussions, and on draft CfV), as
 many project members felt that some recent votes were a bit rushed, and
 did not allow enough time for public review.

Hi Lucas and TC,

in the case of issue #741573 (On menu systems) that I raised in April, I
would like to point out that the CTTE's behaviour makes me feel that my input
was unwelcome.

Here is what I asked:

I am asking you to overrule Bill [who single-handedly reverted a change that
had been discussed, negociated, seconded and accepted] and let me or the Policy
Editors upload an updated version of the Policy containing our changes.

Unfortunately, the TC turned my request into a new project of writing a policy
on menu systems by themselves
(http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems),
and as the result of their lack of time, have not delivered something for the
last six months.

I asked the TC in June to refocus on the core issue (not tolerating Bill's
commit revesal), but there was no answer to my message, and work on writing a
new menu policy continued (sluggishly) without asking input to the main people
that would be affected by the decision, which I find quite illustrative of the
TC's tendency of trying to steer Debian's development.

So please, Technical Comittee, I would like to recommend you to be more
realistic and to better stick to the question that is asked to you, especially
when it is obvious that you do not have enough time to achieve something more
ambitious.  Not to mention that this kind of self-appointment is unwelcome
anyway since is dis-empowers the people who are doing the work.

PS: I am writing the TC because its decisions are collective and I do not
want to make things too personal, but in the case this issue (#741573), I think
that Ian is quite largely responsible for the drift.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117123114.gb2...@falafel.plessy.net

Bug#741573: Two menu systems

[Charles Plessy]

Le Mon, Jun 30, 2014 at 10:25:41PM -0700, Keith Packard a écrit :
 
 I think this does demonstrate that we could, with little effort, allow
 applications to ship only .desktop files and have the menu package take
 those and generate menu files for other systems.

Hi Keith,

your approach is laudable, but most of what you propose has already been
discussed years before, and regardless how little the effort looks like, nobody
ever stepped in to implement it.

Instead, why not making a decision on whether it was acceptable or not to
revert a commit that had been seconded by enough developers and recognised as
consensual by a Policy editor ?  This is the core of the problem: the Policy
changes process works and there is no need for the CTTE to steer Debian's
policy on menus, it is just that the result of one year of consensus-building
it is blocked by a single person.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725001239.GA26509@aqwa.igloo

Bug#741573: Two menu systems

[Charles Plessy]

Le Fri, Jun 27, 2014 at 04:59:50AM -0700, Cameron Norman a écrit :
 
 I believe the major aspect of .desktop files that makes them harder is the
 icon handling. Perhaps debian policy should instruct that a certain icon
 size must always be available in a particular format (e.g. 32x32 png) so
 that WMs do not have to handle so many corner cases in that area.

Hi Cameron,

When working on #707851, I made sure that this is addressed with the input of
Debian maintainers of desktop environments using the FreeDesktop menu.

http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba7
93c9a9e463cca9f7e7b138add8b788   

Here is the relevant extract.

+ Entries displayed in the FreeDesktop menu should conform to the
+ following minima for relevance and visual integration.
+
+ list
+   item
+ Unless hidden by default, the desktop entry must point to a PNG
+ or SVG icon with a transparent background, providing at least
+ the 22times;22 size, and preferably up to 64times;64.  The icon
+ should be neutral enough to integrate well with the default icon
+ themes.  It is encouraged to ship the icon in the default
+ emhicolor/em icon theme directories, or to use an existing
+ icon from the emhicolor/em theme.
+   /item
+
+   item
+ If the menu entry is not useful in the general case as a
+ standalone application, the desktop entry should set the
+ ttNoDisplay/tt key to vartrue/var, so that it can be
+ configured to be displayed only by those who need it.
+   /item
+
+   item
+ In doubt, the package maintainer should coordinate with the
+ maintainers of menu implementations through the
+ emdebian-desktop/em mailing list in order to avoid problems
+ with categories or bad interactions with other icons.  Especially
+ for packages which are part of installation tasks, the contents
+ of the ttNotShowIn/tt/ttOnlyShowIn/tt keys should be
+ validated by the maintainers of the relevant environments.
+   /item
+ /list


I beleive that this part is non-controversial.  The controversy is whether we
should still require with the strenght of a should in the Policy that
packages have to contain a Debian Menu entry, ignoring the fact that a) a lot
of packages have already not respected this point for years, if not decades,
and b) the Debian Menu is not anymore part of standard installations in Jessie.

That is: this part of the patch (reformatted by hand for easier reading).

p
- 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, so that users of the ttmenu/tt package
- will automatically get menu entries in their window
- managers, as well in shells like ttpdmenu/tt.
/p

p
- The menu policy can be found in the ttmenu-policy/tt
- files in the ttdebian-policy/tt package.
- It is also available from the Debian web mirrors at
-  tturl name=/doc/packaging-manuals/menu-policy/
-   
id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt.
/p
 
-   p
- Please also refer to the emDebian Menu System/em
- documentation that comes with the packagemenu/package
- package for information about how to register your
- applications.
+p
+ Packages can, to be compatible with Debian additions to some window
+ managers that do not support the FreeDesktop standard, also provide a
+ emDebian menu/em file, following the emDebian menu policy/em,
+ which can be found in the ttmenu-policy/tt files in the
+ ttdebian-policy/tt package.  It is also available from the Debian
+ web mirrors at tturl name=/doc/packaging-manuals/menu-policy/
+ id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt.
/p

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140629013046.ga21...@falafel.plessy.net

Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

[Charles Plessy]

Le Thu, Apr 10, 2014 at 09:22:47AM +0900, Charles Plessy a écrit :
 Le Wed, Apr 09, 2014 at 11:34:51PM +0100, Ian Jackson a écrit :
  
  It is the demotion of the traditional menu from should to can
  which is controversial.  For the reasons I have already explained, I
  do not agree with that.
 
 yes, it is that part that is controversial, and I would appreciate if the TC
 would focus on it, since this was the original topic of #707851, entitled
 “soften the wording recommending menu files”. 

Dear all,

there are already 65 messages exchanged on this dicsussion (66 with this one),
not to mention the 91 messages in #707851 where, following the Policy changes
process, we reached consensus on Policy's section 9.6 on “Menus”.

The work started on May 11 2013 and ended on Feb 15 2014 with committing
changes in the Policy's Git repository.  On Feb 25 2014, Bill reverted these
changes without discussion (commit 3785878075453e6e3cac7dff8e7607905d24026f).
After failing to engage a productive negociation with Bill, on March 14 2014 I
asked to the TC to decide for us, and informed Bill and the other Policy
editors by an email on the debian-policy mailing list.

More than one month and a half later, Bill still has not explained his position
to the technical comittee.

In that context, I am asking the TC to a) acknowledge that the changes to
section 9.6 after the Policy changes process was followed accordingly, and b)
ask for Bill's commit 378587 be reverted.  In particular, in the absence of
Bill's contribution to the resolution of our conflict, I am asking the TC to
not discuss the menu systems and focus instead on correcting Bill's
misbehaviour.

What is at a stake here is not the Debian Menu system, it is the fact that in
Debian, it takes 5 minutes for one person to block one year of effort and
patience from multiple other persons.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505024529.GA16208@aqwa.igloo

Bug#741573: On menu systems.

[Charles Plessy]

Package: tech-ctte
Severity: normal

Dear technical comittee,

I am asking for your arbitration on an unresolvable conflict on the subject of
Desktop menu systems, between a broad number of developers including on one
hand maintainers of the Debian packages for the GNOME and KDE desktop systems
and the mime-support package (myself), and on the other hand Bill Alombert on
his quality of Policy Editor (DPL delegate).

Over almost one year of work and discussion, including a call for comments on
the debian-devel mailing list, we have shaped a modification to the Debian
Policy that 1) incorporates the description of the FreeDesktop menu system and
its use in Debian for listing program in desktop menus and associating them
with media types, and 2) softens the wording on the Debian Menu system to
reflect that in Jessie it will be neither displayed nor installed by default on
standard Debian installations.

The proposal reached consensus through the Policy Changes process, was seconded
by me, Lisandro Damián Nicanor Pérez Meyer, Cyril Brulebois and Russ Allbery,
who is also Policy Editor and assessed that the consensus was obtained.
Apparently without coordination with the other Policy Editors, Bill then
canceled the change and has been avoiding any concrete discussion the change.

You can find the proposal at the following URL.


http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba793c9a9e463cca9f7e7b138add8b788

The whole discussion is at https://bugs.debian.org/707851.

I will not describe Bill's behaviour in further details unless you ask me to do
so, but the end result is that me and others are stongly dissatisfied by his
obstructive attitude and unilateral veto, to the point that we do not think
that discussion is possible and we need a decision from a third party.  I am
asking you to overrule Bill and let me or the Policy Editors upload an updated
version of the Policy containing our changes.

I will inform Bill and the debian-policy mailing list in the thread for #707851
once I have a bug number for this appeal.

Please let me know if there is further information you need.

Cheers, and many thanks for your work.

-- 
Charles Plessy
Maintainer of the 'mime-support' package
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140314001933.ga29...@falafel.plessy.net

Integration of FreeDestkop standards in the Policy: patch proposed.

[Charles Plessy]

Le Sat, Jan 04, 2014 at 10:28:37AM -0800, Russ Allbery a écrit :
 
 It's been obvious to me that desktop files are a better (and, more
 importantly, more widely supported) representation of this information for
 over six years now, but given that I, as a Policy Editor, don't know how to
 effectively get there from here, I have a hard time blaming the GNOME and KDE
 maintainers for not knowing either.

For the record, here are the links to the message where I just proposed a
patch to the Policy on that matter.  Many thanks to Josselin for initiating
the wording.

 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707851#195
 - 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=200;filename=policy-freedesktop.patch;att=1;bug=707851

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140105060929.GA11722@aqwa.igloo

Soften the the wording recommending menu files: let's do it in Jessie.

[Charles Plessy]

[dropping #727708 as it is getting off-topic]

Le Fri, Jan 03, 2014 at 12:22:44PM +, Ian Jackson a écrit :
 
 Our menu arrangements have been unsatisfactory for some time and I for
 one would certainly be open to change.  Now is probably not the right
 time for this, but maybe after we've dealt with the init system
 question, you'd like to write up a summary of the situation, and
 propose a transition plan.  If the policy editors don't see it your
 way this is certainly something that the TC should be interested in.

Hello Sune and Ian,

The current state of #707851 (‘Soften the wording recommending menu files’) is
that the proposition of Sune and Ian got a positive echo from two Policy
editors.  We then lost momentum, and while Bill's criticism of XDG menu
specification had chilling effects on me, reading again the thread, I do not
see a black-on-white refusal of the core of the proposal itself, and to be fair
I need to say that the final reason why I have not pushed this work further is
the lack of stimulating replies to the wording reshaped by Russ and me.  I
should have been more active and ping directly the participants of the
discussion.

Let's take it positively: with a bit of support (something like seconded,
thank you) from the proponents of the change, we can move #707851 to
acceptance or to a clear definition of what is considered consensus-breaking,
in case there is a precise and unresolvable opposition to some of the changes.

As the maintainer of the mime-support package I have some interset in #707851
and now that I stepped down as a Policy editor, I do not need to be as neutral
as before.  I will restart the discussion, keeping the GNOME and KDE people in
the loop, in order to do what the bug title asks for: soften the wording
recommending menu files.  I hope that it will not be necessary to bother the
TC.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140103141534.GA10529@aqwa.igloo

Bug#681687: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).

[Charles Plessy]

Le Tue, Jul 17, 2012 at 03:51:55PM +, Laszlo Boszormenyi (GCS) a écrit :
 
  It is now visible:
 http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary

Dear all,

I have uploaded to mime-support version 3.53_experimental1 to experimental.

As discussed earlier, me and Laszlo strictly limited the changes to the
adoption of the package, the transfer of its source in collab-maint, and the
addition of a triggered parsing of Desktop entries to populate /etc/mailcap.
Many thanks to Brian M. Carlson for the patch !

We did not have that much time to make extensive tests.  On my computer, I did
not suffer from the lack of a mailcap entry for evince, so please, people
concerned with #658139, test the package and let us know what you think. 

If there is a consensus for uploading to Unstable and ask for a freeze 
exception,
we will.

Here is a link to the diff with the previous version:

http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=commitdiff;hp=3.52-1;h=3.53_experimental1

Here is a link to the build log:

http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=blob;f=amd64.log;h=9a0dace97c2ddd49a03e7c97428cae945ca5f0b0;hb=uploads

(And my apologises for messing with the changelog for my first upload of a
high-priority package...  in contrary of what is written, it was really
uploaded ot experimental...)

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#681687: missing mime entry

[Charles Plessy]

 On Sun, 2012-07-22 at 15:24 +0200, Michael Biebl wrote:
   [...]
   The new mime support maintainer team, which took over the package just a
   few days ago, did ask the release team, if it would be possible to still
   apply this patch for wheezy [2].
   [...]
   [2] https://lists.debian.org/debian-release/2012/07/msg01048.html

Dear all,

about the mail discussed above: while it is addressed to Brian and Laszlo,
I made sure that the release team, the technical comitte and the evince
maintainers get a copy so that they can see that things are moving.  But
before getting Laszlo's and Brian's replies, I did not feel like making
promises.

Nevertheless, earlier in http://bugs.debian.org/658139#117, I also wrote the
following to everybody, with the release team, the tech. comittee and the
evince maintainers copied:

 Wouldn't one of the following solutions be acceptable for you ?
 
  - Add the function to mime-support in Wheezy to update /etc/mailcap using
the FreeDesktop menu entry files in /usr/share/applications via dpkg
triggers.
 
  - Do this in Sid, and add back the MIME entries in evince in Wheezy as a
temporary compromise.

To keep both possibilities open - without expressing a particular preference
for one or another - me and Laszlo are limiting ourselves to work on the
conversion from Desktop to mailcap, with exceptions limited to packaging
updates that I hope will not prevent our package to be reviewed by the release
team if the consensus is to update mime-support in Wheezy. 

We are getting ready to upload to experimental; things go a bit slowly because
time zone effects inserts some delays between our email exchanges, but on the
other hand, I think that it is a good thing as mime-support will be the first
time I work on a package of standard priority.  Also, it happens that the
previous and next week-ends I am not avaiable for Debian work, which postpones
more extensive tests on my side, but I think that an upload to experimental
would be appropriate now.  The last piece missing is that we are looking for a
mailing list address for the Maintainer field, as the trick to send messages to
the PTS do not work because it would create loops.  Or perhaps we can enhance
the PTS to not transmit messages to itself...

I intend to announce on debian-devel that the adoption has been completed after
we uploaded to experimental (Laszlo, you are of course free to do so yourself
if you are the one who uploads).  As Steve noted later in this thread, the
package is already in collab-maint, although I would like to keep an option
option just in case until we upload, that in case we find a defect in the
conversion we might reset it.

  http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#681687: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).

[Charles Plessy]

Le Mon, Jul 16, 2012 at 09:48:47PM +, Laszlo Boszormenyi (GCS) a écrit :
 On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote:
  Laszlo Boszormenyi (GCS) g...@debian.org (16/07/2012):
My intention was to limit people who can commit to mime-support. It
   seems there are multiple viewpoints for example about
   application/x-httpd-* types. One may do more harm with a commit if not
   consulted by a group of more advanced people.  But I'm fine with normal
   collab-maint as well if you and Charles would like that.
  
  As someone processing alioth-related requests, I would find it nice to
  use collab-maint for such projects; but I'm willing to hear about
  arguments against that.
  
  As a random developer, I would really hate to see people fight through
  commits. In case that would happen, I think that can be fixed, IIRC
  collab-maint has some abuse clauses or something similar.
  
  (IOW: I'm not convinced you need a dedicated group; quite the contrary.)
  I already wrote my reason and that a normal collab-maint place is fine
 with me. So I just need to login to git.debian.org and create a
 repository under /git/collab-maint/ right?
 
 Charles, I would add myself as Maintainer and you as an uploader or the
 vica-versa whichever suits you better. Is this OK with you?

Hi Laszlo and Brian,

how about the following (inspired by http://dep.debian.net/deps/dep2/)

Maintainer: mime-supp...@packages.debian.org
Uploaders:
 Laszlo Boszormenyi (GCS) g...@debian.org,
 Charles Plessy ple...@debian.org,

I propose the following action plan.

0) We subscribe to the PTS (done for me).

1) Upload to experimental an adopted package with the updated maintainer and
   uploaders list, the VCS fields updated, and the patch for #497779 applied.

2) Install in Alioth's collab-maint a git repository made with the --debsnap
   option of git-import-dscs, unless we try to go deeper in time ?  Set up
   commits emails to go to the PTS.

3) Make crystal clear in the source package's READMEs that uncoordinated
   commits are an abuse of the collab-maint Alioth group.  But perhaps
   we can allow developers to create topic branches related to bugs in the BTS
   if they like ?

4) Postpone any other change on the main branch until either #681687 (tech.
   comittee) is solved or Wheezy released.

Lastly, I would like to thank Brian for his impressively 16-years long work on
mime-support.  Brian, feel free to stay among the uploaders !

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#681687: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).

[Charles Plessy]

Hello everybody,

http://bugs.debian.org/497779 contains a patch for the mime-support package to
solve this problem for every package that provides a .desktop file but no
mailcap entry.  The mime-support package has been orphaned last week.

Wouldn't one of the following solutions be acceptable for you ?

 - Add the function to mime-support in Wheezy to update /etc/mailcap using
   the FreeDesktop menu entry files in /usr/share/applications via dpkg
   triggers.

 - Do this in Sid, and add back the MIME entries in evince in Wheezy as a
   temporary compromise.

If nobody else volunteers, I propose to start a maintenance group for the
mime-support package, that I would store in a Git repository on Alioth's
collab-maint group.

My background in MIME support is that I maintain packages that declare MIME
types, I keep track of MIME support in the Policy 
(http://bugs.debian.org/661816),
and I wrote much of the MimeTypesSupport page on the Debian wiki
(http://wiki.debian.org/MimeTypesSupport).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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