gtk3 broken/missing icons on kde

[drago01]

On Tuesday, November 5, 2013, Matthias Clasen wrote:

> On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> > On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson <awilliam at redhat.com<javascript:;>>
> wrote:
> > > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> > >> Adam Williamson wrote:
> > >> > I don't think we'd really be correct in blocking the release for
> such
> > >> > issues - especially not Beta. We used to have 'polish' criteria for
> > >> > Final which at least required the icons used in the system menus -
> i.e.
> > >> > what's specified in the app's .desktop file - to be sane for all
> > >> > installed applications, but we dropped that (and other polish
> criteria)
> > >> > with the F19/F20 criteria re-write on the basis that they were
> really
> > >> > stretching a bit too far and would be unlikely to hold up to a 'last
> > >> > blocker before release' acid test. Stuff like this doesn't break
> > >> > anyone's use of the system catastrophically and can reasonably be
> fixed
> > >> > with updates.
> > >>
> > >> But it also affects the live images (making them look very
> unpolished) and
> > >> we don't respin those.
> > >
> > > That's why I said 'reasonably' not 'perfectly' :) I can see an argument
> > > for blocking Final, though in practice, I don't think our current
> > > standards are such that it really makes sense to claim our final
> > > releases are so smooth as to be worth enforcing a high standard of
> > > polish via the blocker mechanisms
> >
> > Then we should that. There is a difference between "perfect" and
> something that
> > looks obviously broken.
>
> Are we really fighting about the classification of fixed bugs here,
>

Yes ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131105/39f289fc/attachment.html>