Hi Larry,

Thanks for bringing the focus back to the 0.10.0 release and looking to
close things down. I think the LDAP improvements are great and need to get
released soon. We also have had a fix regarding an encoding regression
that would be good to get in release, KNOX-754 (it could also be in a
0.9.2 though). 

As for the date, I would recommend another week out, 10/31 maybe? I would
hope we can get KNOX-752 in as well if we can allow for some more time.

Sumit.


On 10/17/16, 7:14 AM, "larry mccay" <lmc...@apache.org> wrote:

>Folks -
>
>I would like to start the process of closing down on 0.10.0.
>We still have ~16 open JIRAs designated for 0.10.0 and we need to start
>resolving these or deferring them to 0.11.0.
>
>A number of the KIP-1 related issues have either been resolved or have
>their usecases awaiting testing from one other other JIRAs - for instance
>KNOX-536 LDAP authentication against nested OU is likely accomplishable
>via
>KNOX-537 - Linux PAM Authentication Module. We just need to test it out.
>
>Over the next couple days, I will start moving some issues out to 0.11.0.
>If you have a patch for something in the wings then you may want to get
>this attached along with tests to help get it committed in time for the
>release.
>
>I know that we were targeting 9/23 for this release but vacations and
>other
>commitments have made it slip.
>I propose that we try and target 10/23 to have an RC available for
>testing.
>
>Thoughts?
>
>thanks!
>
>--larry
>
>On Wed, Aug 10, 2016 at 9:34 AM, Sumit Gupta <sumit.gu...@hortonworks.com>
>wrote:
>
>> That would be awesome Zac. Let me know when you get close, as promised
>> before I would be happy to help with the integration into the main line
>> (build/packing etc).
>>
>> We should also create a JIRA other than KNOX-727 to track and discuss
>> this. There may be one already and I just missed itÅ 
>>
>> Sumit
>>
>>
>> On 8/10/16, 12:54 AM, "Zac Blanco" <zacdbla...@gmail.com> wrote:
>>
>> >I've been working on the admin page on and off over the last month. If
>> >we're aiming for read-only then I think I should have something up in a
>> >week or so. (If I'm only working with the current feature set of the
>>admin
>> >API).
>> >
>> >Definitely doable for 0.10.0.
>> >
>> >On Aug 9, 2016 1:40 PM, "Sumit Gupta" <sumit.gu...@hortonworks.com>
>> wrote:
>> >
>> >9/23 is a good goal for 0.10.0. +1.
>> >
>> >
>> >On 8/9/16, 4:16 PM, "larry mccay" <lmc...@apache.org> wrote:
>> >
>> >>Yes, 1.5 months gets a +1 from me.
>> >>Should we call it 9/23rd?
>> >>
>> >>Metrics and a read-only admin page for that timeframe sound great.
>> >>
>> >>Personally, I would like to see an admin page and some uptake of LDAP
>> >>improvements before we stamp a 1.0.0.
>> >>I could be convinced to go before anyone wants to try. :)
>> >>
>> >>On Tue, Aug 9, 2016 at 4:10 PM, Sumit Gupta
>><sumit.gu...@hortonworks.com
>> >
>> >>wrote:
>> >>
>> >>> Hey Larry,
>> >>>
>> >>> Thanks for reviving the thread.
>> >>>
>> >>> LDAP improvements seems like a decent theme and there is definitely
>>a
>> >>> bunch of work to be done there.
>> >>>
>> >>> A couple of other things that would be good to have before we go
>>for a
>> >>>1.0
>> >>> are (so we could consider including it in 0.10.0):
>> >>>
>> >>> 1. Adding metrics capabiltiies (so that we can get to metering and
>> >>> throttling) : KNOX-643
>> >>> 2. A basic admin UI : KNOX-727? (we likely need another JIRA)
>> >>>
>> >>> Also to close the loop on the 0.10.0 vs 1.0.0 question. I think we
>>are
>> >>> saying that 0.10.0 is not a 1.0.0 release. And if so, I +1 that
>> >>>decision.
>> >>>
>> >>> The last thing to call out, is the dev time we are aiming at for the
>> >>>next
>> >>> release. I think I saw 1.5 months mentioned on another thread. I am
>> >>> certainly good with that and will always support the idea of more
>> >>>frequent
>> >>> releases. So +1 from my side to a 1.5 month duration for the next
>> >>>release.
>> >>>
>> >>>
>> >>> Sumit
>> >>>
>> >>>
>> >>> On 8/7/16, 12:11 PM, "larry mccay" <lmc...@apache.org> wrote:
>> >>>
>> >>> >All -
>> >>> >
>> >>> >Now that we have released 0.9.1 we should resurrect this thread and
>> >>>plan
>> >>> >the theme for 0.10.0 release.
>> >>> >
>> >>> >The filter [1] shows the JIRAs currently set for Fix Version
>>0.10.0,
>> >>>just
>> >>> >as my previous proposal on this thread, it seems that LDAP related
>> >>> >improvements are the dominate theme.
>> >>> >
>> >>> >With recent JIRA filings and patches provided, we have identified a
>> >>>few
>> >>> >pain points related to LDAP search/lookup.
>> >>> >A couple different approaches to optimize the group lookup may be
>> >>> >competing, separate options or complementary - we need to
>>rationalize
>> >>> >exactly what optimizations are needed as part of this release.
>> >>> >
>> >>> >I will create a wiki page for Knox Improvement Proposal for the
>>LDAP
>> >>> >improvements where we can capture the direction and implementation
>> >>>details
>> >>> >for this as the central theme for 0.10.0.
>> >>> >
>> >>> >Thoughts on the theme and KIP page for capturing a coherent
>>proposal?
>> >>> >
>> >>> >thanks,
>> >>> >
>> >>> >--larry
>> >>> >
>> >>> >[1] -
>> >>> >https://issues.apache.org/jira/browse/KNOX-461?jql=
>> >>> project%20%3D%20KNOX%20
>> >>> >AND%20status%20%3D%20Open%20AND%20resolution%20%3D%
>> >>> 20Unresolved%20AND%20fi
>> >>> >xVersion%20%3D%200.10.0%20ORDER%20BY%20due%20ASC%2C%
>> >>> 20priority%20DESC%2C%2
>> >>> >0created%20ASC
>> >>> >
>> >>> >On Mon, Jun 6, 2016 at 11:11 AM, larry mccay <lmc...@apache.org>
>> >>>wrote:
>> >>> >
>> >>> >> Hi Sumit -
>> >>> >>
>> >>> >> I'm sorry that I missed this email!
>> >>> >>
>> >>> >> I am +1 on you as the release manager.
>> >>> >>
>> >>> >> I think that we should probably identify the driving features for
>> >>>0.10.0
>> >>> >> first and then follow up that discussion with whether or not we
>>can
>> >>>make
>> >>> >> this a 1.0.0 but I believe that we would need to ensure two
>>things:
>> >>> >>
>> >>> >> 1. package name clean up
>> >>> >> 2. API, programming model definition - once we go 1.0.0 we have
>> >>> >>different
>> >>> >> requirements for backward compatibility
>> >>> >>
>> >>> >> Are we happy with the ClientDSL model, with various base classes
>>for
>> >>> >> providers, etc?
>> >>> >>
>> >>> >> In terms of features for 0.10.0 - I have a couple in mind:
>> >>> >>
>> >>> >> 1. Centralized LDAP configuration that can be used across
>>multiple
>> >>> >> topologies
>> >>> >> 2. Integration of the hadoop group lookup pluging as an identity
>> >>> >>assertion
>> >>> >> extension (LDAP, unix, etc)
>> >>> >> 3. Group lookup API for KnoxSSO extension
>> >>> >> 4. Logout API for KnoxSSO
>> >>> >> 5. Service description pages - perhaps test pages
>> >>> >>
>> >>> >> Thoughts?
>> >>> >>
>> >>> >> --larry
>> >>> >>
>> >>> >>
>> >>> >> On Thu, May 12, 2016 at 1:19 PM, sumit gupta <su...@apache.org>
>> >>>wrote:
>> >>> >>
>> >>> >>> In light of the recent 0.9.1 planning discuss thread, I thought
>>I
>> >>> >>> would take the opportunity to kick off a discussion about the
>>next
>> >>> >>> release for Knox.
>> >>> >>>
>> >>> >>> The main discussion points I have so far for this release are:
>> >>> >>>
>> >>> >>> 1. Should this release be the 1.0.0 release for Knox?
>> >>> >>> 2. What are the main features that we would like to target for
>>this
>> >>> >>> release?
>> >>> >>>
>> >>> >>> Once we decide on the scope of the release we can collectively
>>come
>> >>>up
>> >>> >>> with a target release date. I would also be happy to volunteer
>>as
>> >>>the
>> >>> >>> release manager for this release, if there is no objection.
>> >>> >>>
>> >>> >>> In relation to point number 1, I would be interested in seeking
>> >>> >>> opinion on what we would like to do in terms of package names or
>> >>>any
>> >>> >>> other changes to the structure of the source or build. I'm not
>>sure
>> >>>if
>> >>> >>> there is a set of conventions or guidelines for an Apache
>>project
>> >>>to
>> >>> >>> follow when releasing a 1.0.0, so any insight or advice there
>>would
>> >>> >>> also be greatly appreciated.
>> >>> >>>
>> >>> >>> Thanks,
>> >>> >>> Sumit.
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>>
>>

Reply via email to