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 <firstname.lastname@example.org> 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,