Request hold 3.6.3 final release for fdo#53474 - Windows Accessibility

[Michael Meeks]

Hi Stuart,

On Thu, 2012-10-25 at 10:26 -0500, V Stuart Foote wrote:
> Would ask to have 3.6.3 final release held, and proceed with a 3.6.3.
> rc3 build.

	I reviewed & merged it to -3-6, it was reasonably trivial - had it been
proposed in good time for -3-6-3 we could have got another couple of
reviews, so that's sad - we were busy this minor release cycle.
Actually, simply posting a mail with [REVIEW-3-6-3] a11y fix - with a
link to the patch and a plea for a couple of reviews might have done it
for you.
 
> Stephan Bergmann's Patch for fdo#53474 requires some testing, but if
> fully functional will return Java Accessibility based Assistive
> Technology support to the Windows users that otherwise can not use
> LibreOffice.

	There is always LibreOffice 3.5.x of course. Of course, more testing
and fixing in the a11y area is always appreciated.

	In terms of delaying 3.6.3 - that is a really big ask - there is a
really significant release engineering and schedule re-arrangement cost
for that. Many of the builds are already complete, and already
up-loading / synchronising to mirrors.

	In general time-based releases should ship on time - that encourages
people to test in a timely fashion, and the freeze for 3.6.4 is only
~two weeks away.

	Were we to have another new very significant brown-paper-bag 3.6.x
regression bug - fails-to-start, looses-all-data-on-save or something -
forcing us to do a 3.6.3rc3 then we'd want to get that fix in as we did
that - but (hopefully) that is really the exception not the norm.

> Proceeding with 3.6.3 rc2 designation as final ignores what by
> convention should have been a blocker at the 3.6.0 transition to
> gbuild.

	If it had been found and correctly prioritised before the last RC for
3.6.0 (incidentally - thanks for your work bringing attention to the
issue), it would have been fixed for that I suspect. However - it seems
clear that no-one tested this and/or filed bugs before the 3.6.0
release.

> I'm sure there are a couple of other issues that could probably be
> buttoned up with back ports, and with the prominence of the Berlin
> conference--risk of slipping 3.6.3 final release a day or two to
> assure functional accessibility with an additional rc3 build seems
> warranted.

	There are always a huge risks of slipping releases: particularly moral
hazard: that it is not fair on those who did their testing in a timely
way, and those who worked hard to get their bugs fixed in time for the
deadlines. Worse, the knock-on effect of people thinking that we're not
serious about our schedule is in itself toxic leading to endless slips.

	So - IMHO - this is a regrettable bug affecting a population of users
on Windows that we care about, but we can't hold the 3.6.3 release based
only on this. In the meantime (I hope) our just released 3.5.7 continues
to work.

	The positive news here is that Tor fixed a whole cluster of
long-standing a11y related crashers in 3.6.3 for the Mac and of course
the Unix/atk a11y should continue to work in 3.6.x. If window users are
eager to get the fix they can download a dev-build / snapshots of the
-3-6 branch, and we will have the real fix in 3.6.4 in ~a month.

	Moving ahead, what would -really- help would be to have more testing &
bug reports against master - which (generally) is in quite a good state
vs. 3.6 and should be usable. Indeed, if people really want to be
connected to development, and have every one of their -regression- bugs
taken really seriously, talked through in the ESC calls etc. they need
to be filing them vs. master/3.7 - where the bugs are most easy to find
and fix.

	Sorry if that's a hard response, I understand it's a serious issue; and
thanks so much for testing, and helping to debug this issue.

	All the best,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot