[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: Comparison of Options AB and D

On Aug 30 2015, Sam Hartman <hartmans@debian.org> wrote:
>>>>>> "Nikolaus" == Nikolaus Rath <Nikolaus@rath.org> writes:
>     Nikolaus> On Aug 29 2015, Sam Hartman <hartmans@debian.org> wrote:
>     >> Option D goes further.  Option D requires that packages drop
>     >> their traditional menu entries if they ship .desktop files.
>     >> (That's done on a per-application not per-package basis).
>     Nikolaus> That would be a pretty ridiculous situation. So package
>     Nikolaus> maintainers would be free to ship .desktop files as well
>     Nikolaus> menu files for their favorite third menu system, but they
>     Nikolaus> *must not* ship menu files for the traditional debian
>     Nikolaus> menu?
> correct.
>     Nikolaus> Surely there is no need to single out the traditional menu
>     Nikolaus> as something that must not be used. It's sufficient if
>     Nikolaus> policy mandates the use of .desktop files, anything beyond
>     Nikolaus> that ought to be entirely up to the maintainer.
> I think the argument in favor of this need is that we're trying to force
> a transition of the traditional menu to .desktop as a metadata format.

Indeed. The question is why.

A. This comes very close to design work which the CTTE should not be
   doing. If there's a conflict between two crappy designs and the CTTE
   is asked to rule, then you should pick the less crappy one or decline
   to rule, not create an entirely new design.

   Having a central design body for Debian may not actually be a bad
   idea, but experience (as from this bug) has shown that the CTTE does
   not have the necessary manpower.

B. Even if the CTTE were supposed to do design work, or if this clearly
   was not design work, it's still not what the CTTE has been asked. You
   were asked to override a maintainer.

C. Even if you were supposed to do design work, and had been asked to do
   so in this case, who would actually benefit from a forced transition?

   - It's certainly not the current users of the traditional menu. In
     the short term there worse off (because the menu will become
     smaller), and in the long term they can write a converter to matter
     if there's a forced transition or not.

   - It's probably not the users of .desktop files either (they don't
     want all the additional entries).

   - It's also not the maintainers (if shipping traditional menu files
     is a burden, they can stop doing so even if policy doesn't force
     them to remove them).

   So who is benefitting?

D. Even if you were supposed to do design work, were asked to do so in
   this case, and I forget someone who benefits from this forced
   transition, was it really worth delaying a decision for more than a
   year and a release cycle? It's not that overruling Bill a year ago
   would somehow made a forced transition later on impossible.

I think a lot of things went wrong here.


GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Reply to: