I'm on the fence about an 0.9 vs a 1.0.  A 1.0 means fixing the package names 
to me mostly.  Breaking backwards compatibility is always a difficult decision.




On 3/8/16, 9:55 AM, "Kevin Minder" <[email protected]> wrote:

>Larry,
>I'm +1 on the content, timing and you being RM.
>Kevin.
>
>
>
>
>On 3/8/16, 9:22 AM, "larry mccay" <[email protected]> wrote:
>
>>All -
>>
>>I'd like to volunteer to be the release manager for the 0.9.0 release
>>unless someone else would like to take it instead.
>>
>>In addition, I think that we need to scope the release and driving usecases
>>and a target date for the release.
>>
>>We currently have ~25 JIRAs slated for 0.9.0 and most fall into one or more
>>of the following categories:
>>
>>* dependency upgrades and related fixes
>>* proxying of UIs for Ambari and Ranger and related issues
>>* the hosting of web applications
>>* the addition of an application for a default KnoxSSO form based login
>>* PAM authentication provider - MISSING DOCs and TESTs
>>* various bug fixes and incremental improvements
>>
>>It seems that around half of these are already set to fixed.
>>
>>If there are additional issues that folks would like to get into the 0.9.0
>>release then we should discuss anything that would require a sizable change
>>and file JIRAs for them asap.
>>
>>I believe that from the above categories that we can adjust the driving
>>usecases from the 0.8.0 release to reflect the shift of focus from external
>>applications to:
>>
>>1. SSO participation by applications like Ranger and Ambari while being
>>proxied through the gateway.
>>
>>2. Authentication natively done by Ranger and Ambari applications while
>>being proxied through Knox.
>>
>>3. the usecase of a custom application like the Knoxplorer sample can now
>>be hosted by Knox and this needs to be covered and tested with KnoxSSO.
>>
>>4. Default Knox authentication with form based application as KnoxSSO IDP.
>>
>>5. any additional API support and various features and improvements.
>>
>>It seems to me that we could start considering a 1.0 release. If this seems
>>like a reasonable time to do that then we should open up discussion for any
>>additional improvements or changes that we'd want to include in order to
>>make it our 1.0.
>>
>>Given the above scope and driving usecases, I'd like to propose an end of
>>March release.
>>
>>Thoughts?
>>
>>thanks,
>>
>>--larry

Reply via email to