Paul,

 > support does not imply a proactive "guarantee"

Correct.  There are no guarantees whatsoever.  The license 
<http://www.uportal.org/license.html> even says so.

 > I think it would be good to specifically state that support
 > does not require proactive testing on all supported browsers.

Sounds reasonable to me.  The project should be all about being open and 
forthright about this.  Care to take a crack at wordcrafting those pages 
to reflect this?

Andrew



Paul Gazda wrote:
> Andrew,
> So to rephrase what you are saying, support does not imply a proactive
> "guarantee" that uPortal will run out of the box on the supported browsers,
> but it implies a high priority response to problem reports specific to
> supported browsers. Is that the gist of it?
>
> I did read the section you put on the wiki on what support means, but it
> left me wondering about the proactive testing aspect. I think it would be
> good to specifically state that support does not require proactive testing
> on all supported browsers.
>
> Paul Gazda
> Senior Web Developer
> Information Technology Services
> Northern Arizona University
> [EMAIL PROTECTED]
> (928) 523-6844
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Petro
> Sent: Monday, February 25, 2008 1:49 PM
> To: [email protected]
> Subject: Re: [uportal-dev] uPortal policy on supported web browsers
>
> Paul,
>
> "Support" doesn't mean (at least to me) the project needs to introduce 
> an oppressive amount of manual QA.
>
> "Support" means a distinction on what the response is going to be when a 
> problem is reported, with a higher commitment on the part of uPortal 
> developers on addressing issues raised against supported browsers and 
> much less commitment to do heroics for unsupported browsers.
>
> There's a section on each of those pages that attempts to answer the 
> question of what it means for uPortal to "support" certain browsers.  
> Perhaps that can be made clearer?
>
> Andrew
>
>
>
> Paul Gazda wrote:
>   
>> I like the principal of having officially supported browsers, but wonder
>> about the implementation details. Doesn't supporting only the latest
>>     
> single
>   
>> non-beta version of the YUI listed browsers imply that every release of
>>     
> the
>   
>> uPortal framework or official channels and portlets needs to be tested
>> against 18 combinations of browsers and OSs as listed at YUI? And every
>>     
> time
>   
>> a new release of one of the 5 listed browsers comes out, all of the
>> framework, channels and portlets need to be re-tested against the new
>> browser release? Perhaps I'm mis-interpreting what "support" means, but if
>> not, I am wondering how continuing support for changing browser and OS
>> releases would be assured.
>>
>> Paul Gazda
>> Senior Web Developer
>> Information Technology Services
>> Northern Arizona University
>> [EMAIL PROTECTED]
>> (928) 523-6844
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Petro
>> Sent: Monday, February 25, 2008 11:39 AM
>> To: [email protected]
>> Subject: [uportal-dev] uPortal policy on supported web browsers
>>
>> uPortal developers,
>>
>> I'd like to see the project adopt a policy about what web browsers 
>> uPortal supports.  Fortunately, the Yahoo YUI folks have an A-grade 
>> browser policy that I think[1] tracks very well with what uPortal 
>> support ought to be.  Making the policy that of supporting YUI-graded 
>> A-grade browsers has some very nice properties in that they keep the 
>> list up to date and so uPortal will have a go-to, commonly respected, 
>> external criteria rather than dithering internally about which browsers 
>> to support.
>>
>> I've drafted a policy statement in the uPortal manuals:
>>
>> uP3 manual: http://www.ja-sig.org/wiki/x/LYKi
>>
>> uP2 manual: http://www.ja-sig.org/wiki/x/LIKi
>>
>> I'd like for one of two things to happen:
>>
>> 1) A flurry of +1s and "huzzahs" sufficient to adopt this browser 
>> support policy, so that we have one, making the project more marketable 
>> and setting a path.
>>
>> 2) responses leading to discussion that brings us to an even better 
>> policy statement, for which we can then have (1).
>>
>> Thanks,
>>
>> Andrew
>>
>> [1]: Thanks are due to Colin Clark, the rest of uPortal steering 
>> committee, and Gary Thompson in helping me to become informed enough to 
>> think about this.
>>
>>
>>   
>>     
>
>
>   


-- 
Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: 
The Community Source Way!"
April 27th - 30th, 2008 in St. Paul, Minnesota USA

Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and 
more!
Information/Registration at: 
http://www.ja-sig.org/conferences/08spring/index.html

You are currently subscribed to [email protected] as: [EMAIL 
PROTECTED]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Reply via email to