Right, I think this is a good approach + the caveats Daniel suggests. I think the policy around accepting patches should be along the lines of the level of guarantee we plan to offer e.g. for "no guarantee" on support we also offer "no guarantee" re accepting patches i.e. if we can reasonably accept the patch we will (no/low effort and risk etc), otherwise sorry.
I'll create a wiki page based on this and we can start filling it in. I think maybe part of this will depend on the support matrix of some of the framework's Jenkins ui currently depends on e.g. YUI. On Saturday, August 9, 2014 11:09:31 AM UTC+1, Daniel Beck wrote: > > > On 07.08.2014, at 22:36, Stephen Connolly <stephen.al...@gmail.com > <javascript:>> wrote: > > > I think what we are after is 3 tiers: > > > > - first class UX (we should aim to proactively fix these browsers and > provide an equal UX across all) - UI testing failures here are considered > major UI bugs > > - best effort UX (we will accept patches to fix issues and attempt to > ensure there is at least one way to do any action with these browsers) - UI > testing failures here are only considered major bugs if they completely > block functionality, if the UX degrades but remains functional or if there > is another way to do it, then it's a minor bug > > - no guarantees - no UI testing - UI bugs closed as will not fix > > > > So IE 11 should be first class, say IE 8 or 9 is best effort and IE 7 > and below is no guarantees > > This looks like a good approach. Except maybe still accept patches for 'no > guarantees', if it's simple enough and doesn't impact supported browsers, > with no commitment to keep them working. > > Given Microsoft's recent announcement[1] and negligible Vista market > share[2], we should be able to drop IE8+9 from 'best effort' sooner rather > than later. > > Suggestions for first class UX in other browsers (in case this is ever > relevant): > * For regular Chrome and Firefox, working in the latest major release > should be enough: It'll take changes ~2 weeks (for regular releases) to at > least ~8 weeks (LTS) to reach users, which should be enough to update the > browser to its latest & greatest. > * Firefox ESR support shouldn't be too much effort, given they're never > older than ~1 year (Firefox 24 ESR was released September 2013 and is > currently being replaced by Firefox 31 ESR). > * 90+% of OS X users seem to be able[3] to have at least Safari 6.1[4] > * No support for alpha/beta/canary releases. Make this explicit. > > What about Android, iOS, Windows Phone? > > 1: > http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx > > 2: > https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers > > 3: http://update.omnigroup.com/ Overall ยป Major Version > 4: https://en.wikipedia.org/wiki/Safari_%28web_browser%29#Safari_7 > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
