Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

Okay, All -

I am serious this time.
Planning to branch for 0.13.0 this weekend or early next week.

I will be reviewing and committing outstanding patches that are ready to go
and looking to get an RC next week.

The following are the current outstanding JIRAs for 0.13.0.
If anyone has any additional issues that should be considered critical for
0.13.0 please file a JIRA or set the Fix Version to 0.13.0 for
consideration.

TPatch InfoKeySummaryAssigneeReporterPStatusResolutionCreatedUpdatedDue
[image: Bug]
 KNOX-979


Documentation for Atlas UI & Atlas Rest Api via Knox Proxy

Nixon Rodrigues

Nixon
Rodrigues

[image:
Major] PATCH AVAILABLE *Unresolved* 06/Jul/17 02/Aug/17

[image: Task]
 KNOX-976


Add Jupyter Kernel Gateway Service Definitions

Jesus Alvarez
 Jesus
Alvarez
 [image:
Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 19/Jul/17

[image: Bug]
 KNOX-972


Update Hbase UI service 
Jeffrey E Rodriguez

Jeffrey
E Rodriguez

[image:
Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 03/Aug/17 23/Jun/17

[image: New Feature]
 KNOX-789


Apache Atlas REST API support

Nixon Rodrigues

Jeffrey
E Rodriguez

[image:
Major] REOPENED *Unresolved* 15/Nov/16 03/Aug/17   Actions

Thanks,

--larry

On Mon, Jun 26, 2017 at 12:35 PM, Jeffrey Rodriguez 
wrote:

> Thanks for you efforts to resolve the encoding issues.
>
> Being that most of this changes were introduce to help with Ambari URL
> mapping.
>
> These changes cause some grief to us (my team) when moving to Knox 0.11.0
> and some of the UIs we supported would break.
>
> Instead of making such a general changes and being that UIs don't follow a
> spec. thus we may run into special cases. It would have been nice to make
> the encoding an "optional" attribute thus the changes could have been made
> just for Ambari  UI URL or any other UI that require these changes for
> encoding.
>
> On a related topic, it is very hard to support different versions of the UI
> even with versioning. The issue is that most of the times we don't know
> what has changed and rules that used to work may not work. Here is the need
> to have a tool to test the UI in a systematic way. We thought of a crawling
> tool but that presented other challenges. I bring this up so we may discuss
> UI rewrites which different of REST which are APIs change from version to
> version,  also UI page are more complex in style and way to manipulate
> requests/responses.
>
> Regards,
> Jeff Rodriguez
>
>
>
>
> On Mon, Jun 26, 2017 at 8:47 AM, larry mccay  wrote:
>
> > While working on the encoding issues, we have had a number of JIRAs filed
> > for updated UI service definitions.
> > I know this happens to be a sore spot for many deployments since many
> have
> > become obsolete.
> > UIs are such a moving target.
> >
> > I would like to try and wait to get these patches in for the 0.13.0
> > release.
> >
> > We also have some additional verification of the encoding fix outstanding
> > and we are waiting treating this as a blocker for the release.

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[Jeffrey Rodriguez]

Thanks for you efforts to resolve the encoding issues.

Being that most of this changes were introduce to help with Ambari URL
mapping.

These changes cause some grief to us (my team) when moving to Knox 0.11.0
and some of the UIs we supported would break.

Instead of making such a general changes and being that UIs don't follow a
spec. thus we may run into special cases. It would have been nice to make
the encoding an "optional" attribute thus the changes could have been made
just for Ambari  UI URL or any other UI that require these changes for
encoding.

On a related topic, it is very hard to support different versions of the UI
even with versioning. The issue is that most of the times we don't know
what has changed and rules that used to work may not work. Here is the need
to have a tool to test the UI in a systematic way. We thought of a crawling
tool but that presented other challenges. I bring this up so we may discuss
UI rewrites which different of REST which are APIs change from version to
version,  also UI page are more complex in style and way to manipulate
requests/responses.

Regards,
Jeff Rodriguez




On Mon, Jun 26, 2017 at 8:47 AM, larry mccay  wrote:

> While working on the encoding issues, we have had a number of JIRAs filed
> for updated UI service definitions.
> I know this happens to be a sore spot for many deployments since many have
> become obsolete.
> UIs are such a moving target.
>
> I would like to try and wait to get these patches in for the 0.13.0
> release.
>
> We also have some additional verification of the encoding fix outstanding
> and we are waiting treating this as a blocker for the release.
>
> I will be making another pass through the open JIRAs shortly in order to
> push things out to the next release for managing scope of 0.13.0.
>
> Thank you for your patience!
>
> On Thu, Jun 8, 2017 at 9:12 AM, larry mccay  wrote:
>
> > All -
> >
> > Just an FYI - I am currently trying to resolve a number of url encoding
> > related issues that were introduced by a change to get proxying of Ambari
> > UI working properly.
> >
> > Personally, I feel this is a blocker and would like to get a fix in for
> > 0.13.0.
> > At the same time, we may determine that most of the issues are edge cases
> > or at least not very common.
> > I am aware of WebHDFS issues with spaces in the filename or path and
> HBase
> > related issues where reserved characters such as '/' are being used.
> >
> > It appears that this has been introduced by trying to accommodate
> Ambari's
> > use of an unwise character '|' in its URLs.
> > A general approach of encoding and decoding the URL has led to a number
> of
> > inconsistencies with what the backend services expect.
> >
> > I will attempt to find the most surgical and least invasive fix for this
> > issue as to reduce risk for 0.13.0 closedown.
> >
> > thanks,
> >
> > --larry
> >
> > On Wed, May 24, 2017 at 9:49 AM, Sandeep More 
> > wrote:
> >
> >> Ah ! got it.
> >>
> >>
> >> On Wed, May 24, 2017 at 9:46 AM, larry mccay  wrote:
> >>
> >>> Actually, what I am proposing is that we *branch* on Monday and double
> >>> commit as necessary in order to close down before the rc and through
> the
> >>> release process. I'd like to get to a rc by the end of next week - 6/2
> - if
> >>> not sooner.
> >>>
> >>> We will also likely need to double commit bug fixes to master and
> 0.13.0
> >>> branch for some time in case we need a new 0.13.x release to avoid the
> >>> 1.0.0 refactoring for existing deployments.
> >>>
> >>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More 
> >>> wrote:
> >>>
>  Hello Larry,
> 
>  Thanks for starting the discussion, given that we are away from the
>  target date just by a week I too think that releasing 0.13.0 on
> Monday and
>  then working towards 1.0.0 (package refactoring) would be a good
> idea. One
>  upshot of this is that we don't have to double commit as we had
> initially
>  thought :)
> 
>  Best,
>  Sandeep
> 
>  On Tue, May 23, 2017 at 4:44 PM, larry mccay 
> wrote:
> 
> > All -
> >
> > As we targeted a 5/31 date for the release of 0.13.0, I think we need
> > to look at managing the current scope for 0.13.0 as well as the plan
> for a
> > 1.0.0 again.
> > Since we are just a week away from the target date, I think that
> > refactoring the package names for the 1.0.0 release at the same time
> is a
> > stretch.
> >
> > We currently have 22 or so JIRAs and will not be able to get them all
> > into 0.13.0.
> > What do you think about the following:
> >
> > * We manage the existing scope over the rest of this week.
> > * I will post comments on some JIRAs about potentially moving them
> out
> > and without any movement will move them out by Friday 26th.
> > * JIRAs that I think are outside the KIPs that are driving the
> release
> > or that may destabilize the release I will just move.
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

While working on the encoding issues, we have had a number of JIRAs filed
for updated UI service definitions.
I know this happens to be a sore spot for many deployments since many have
become obsolete.
UIs are such a moving target.

I would like to try and wait to get these patches in for the 0.13.0 release.

We also have some additional verification of the encoding fix outstanding
and we are waiting treating this as a blocker for the release.

I will be making another pass through the open JIRAs shortly in order to
push things out to the next release for managing scope of 0.13.0.

Thank you for your patience!

On Thu, Jun 8, 2017 at 9:12 AM, larry mccay  wrote:

> All -
>
> Just an FYI - I am currently trying to resolve a number of url encoding
> related issues that were introduced by a change to get proxying of Ambari
> UI working properly.
>
> Personally, I feel this is a blocker and would like to get a fix in for
> 0.13.0.
> At the same time, we may determine that most of the issues are edge cases
> or at least not very common.
> I am aware of WebHDFS issues with spaces in the filename or path and HBase
> related issues where reserved characters such as '/' are being used.
>
> It appears that this has been introduced by trying to accommodate Ambari's
> use of an unwise character '|' in its URLs.
> A general approach of encoding and decoding the URL has led to a number of
> inconsistencies with what the backend services expect.
>
> I will attempt to find the most surgical and least invasive fix for this
> issue as to reduce risk for 0.13.0 closedown.
>
> thanks,
>
> --larry
>
> On Wed, May 24, 2017 at 9:49 AM, Sandeep More 
> wrote:
>
>> Ah ! got it.
>>
>>
>> On Wed, May 24, 2017 at 9:46 AM, larry mccay  wrote:
>>
>>> Actually, what I am proposing is that we *branch* on Monday and double
>>> commit as necessary in order to close down before the rc and through the
>>> release process. I'd like to get to a rc by the end of next week - 6/2 - if
>>> not sooner.
>>>
>>> We will also likely need to double commit bug fixes to master and 0.13.0
>>> branch for some time in case we need a new 0.13.x release to avoid the
>>> 1.0.0 refactoring for existing deployments.
>>>
>>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More 
>>> wrote:
>>>
 Hello Larry,

 Thanks for starting the discussion, given that we are away from the
 target date just by a week I too think that releasing 0.13.0 on Monday and
 then working towards 1.0.0 (package refactoring) would be a good idea. One
 upshot of this is that we don't have to double commit as we had initially
 thought :)

 Best,
 Sandeep

 On Tue, May 23, 2017 at 4:44 PM, larry mccay  wrote:

> All -
>
> As we targeted a 5/31 date for the release of 0.13.0, I think we need
> to look at managing the current scope for 0.13.0 as well as the plan for a
> 1.0.0 again.
> Since we are just a week away from the target date, I think that
> refactoring the package names for the 1.0.0 release at the same time is a
> stretch.
>
> We currently have 22 or so JIRAs and will not be able to get them all
> into 0.13.0.
> What do you think about the following:
>
> * We manage the existing scope over the rest of this week.
> * I will post comments on some JIRAs about potentially moving them out
> and without any movement will move them out by Friday 26th.
> * JIRAs that I think are outside the KIPs that are driving the release
> or that may destabilize the release I will just move.
>
> If I move something that is something wanted by you, please feel free
> to add it back, comment or raise discussion on this thread.
>
> I also propose that we branch for 0.13.0 on Monday 5/29th and work
> toward getting the rest of the required issues in and an RC by the 31st or
> by end of the week. Once we release 0.13.0, we should refactor master for
> the 1.0.0 release - concentrate on closing down any fallout from package
> name changes and do an immediate 1.0.0 release.
>
> Thoughts?
>
> thanks,
>
> --larry
>
>
> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More 
> wrote:
>
>> Sounds great !
>>
>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay 
>> wrote:
>>
>> > That sounds reasonable to me.
>> > I was hoping to get as many of the patches available and important
>> bugs
>> > fixed before the split as well.
>> > Minimizing the double commits/patches is definitely in our interest.
>> >
>> > At the same time, we need to have enough time to spend on
>> refactoring as
>> > well.
>> > I'm thinking that May 15th may be a good branch point - giving us 2
>> weeks
>> > to concentrate on repackaging and adapter classes.
>> >
>> >
>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
>> moresand...@gmail.com>
>> > wrote:
>> >
>> > > Oh,

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

All -

Just an FYI - I am currently trying to resolve a number of url encoding
related issues that were introduced by a change to get proxying of Ambari
UI working properly.

Personally, I feel this is a blocker and would like to get a fix in for
0.13.0.
At the same time, we may determine that most of the issues are edge cases
or at least not very common.
I am aware of WebHDFS issues with spaces in the filename or path and HBase
related issues where reserved characters such as '/' are being used.

It appears that this has been introduced by trying to accommodate Ambari's
use of an unwise character '|' in its URLs.
A general approach of encoding and decoding the URL has led to a number of
inconsistencies with what the backend services expect.

I will attempt to find the most surgical and least invasive fix for this
issue as to reduce risk for 0.13.0 closedown.

thanks,

--larry

On Wed, May 24, 2017 at 9:49 AM, Sandeep More  wrote:

> Ah ! got it.
>
>
> On Wed, May 24, 2017 at 9:46 AM, larry mccay  wrote:
>
>> Actually, what I am proposing is that we *branch* on Monday and double
>> commit as necessary in order to close down before the rc and through the
>> release process. I'd like to get to a rc by the end of next week - 6/2 - if
>> not sooner.
>>
>> We will also likely need to double commit bug fixes to master and 0.13.0
>> branch for some time in case we need a new 0.13.x release to avoid the
>> 1.0.0 refactoring for existing deployments.
>>
>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More 
>> wrote:
>>
>>> Hello Larry,
>>>
>>> Thanks for starting the discussion, given that we are away from the
>>> target date just by a week I too think that releasing 0.13.0 on Monday and
>>> then working towards 1.0.0 (package refactoring) would be a good idea. One
>>> upshot of this is that we don't have to double commit as we had initially
>>> thought :)
>>>
>>> Best,
>>> Sandeep
>>>
>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay  wrote:
>>>
 All -

 As we targeted a 5/31 date for the release of 0.13.0, I think we need
 to look at managing the current scope for 0.13.0 as well as the plan for a
 1.0.0 again.
 Since we are just a week away from the target date, I think that
 refactoring the package names for the 1.0.0 release at the same time is a
 stretch.

 We currently have 22 or so JIRAs and will not be able to get them all
 into 0.13.0.
 What do you think about the following:

 * We manage the existing scope over the rest of this week.
 * I will post comments on some JIRAs about potentially moving them out
 and without any movement will move them out by Friday 26th.
 * JIRAs that I think are outside the KIPs that are driving the release
 or that may destabilize the release I will just move.

 If I move something that is something wanted by you, please feel free
 to add it back, comment or raise discussion on this thread.

 I also propose that we branch for 0.13.0 on Monday 5/29th and work
 toward getting the rest of the required issues in and an RC by the 31st or
 by end of the week. Once we release 0.13.0, we should refactor master for
 the 1.0.0 release - concentrate on closing down any fallout from package
 name changes and do an immediate 1.0.0 release.

 Thoughts?

 thanks,

 --larry


 On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More 
 wrote:

> Sounds great !
>
> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay 
> wrote:
>
> > That sounds reasonable to me.
> > I was hoping to get as many of the patches available and important
> bugs
> > fixed before the split as well.
> > Minimizing the double commits/patches is definitely in our interest.
> >
> > At the same time, we need to have enough time to spend on
> refactoring as
> > well.
> > I'm thinking that May 15th may be a good branch point - giving us 2
> weeks
> > to concentrate on repackaging and adapter classes.
> >
> >
> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
> moresand...@gmail.com>
> > wrote:
> >
> > > Oh, I guess it depends on when we split, I was planning on taking
> up the
> > > new feature (mentioned in earlier email).
> > > If we decide to go for the feature I was hoping to get it in sooner
> > (before
> > > the split) if possible.
> > >
> > >
> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay 
> wrote:
> > >
> > > > Actually, I meant 5/31 for a release date.
> > > > You think that is too early for a repackaged and narrowly scoped
> 1.0.0?
> > > >
> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
> moresand...@gmail.com>
> > > > wrote:
> > > >
> > > > > Great, thanks Larry for starting the discussion and the KIP !
> > > > >
> > > > > May 31st target date sounds good, just to be sure, this date
> is when

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

Actually, what I am proposing is that we *branch* on Monday and double
commit as necessary in order to close down before the rc and through the
release process. I'd like to get to a rc by the end of next week - 6/2 - if
not sooner.

We will also likely need to double commit bug fixes to master and 0.13.0
branch for some time in case we need a new 0.13.x release to avoid the
1.0.0 refactoring for existing deployments.

On Wed, May 24, 2017 at 9:29 AM, Sandeep More  wrote:

> Hello Larry,
>
> Thanks for starting the discussion, given that we are away from the target
> date just by a week I too think that releasing 0.13.0 on Monday and then
> working towards 1.0.0 (package refactoring) would be a good idea. One
> upshot of this is that we don't have to double commit as we had initially
> thought :)
>
> Best,
> Sandeep
>
> On Tue, May 23, 2017 at 4:44 PM, larry mccay  wrote:
>
>> All -
>>
>> As we targeted a 5/31 date for the release of 0.13.0, I think we need to
>> look at managing the current scope for 0.13.0 as well as the plan for a
>> 1.0.0 again.
>> Since we are just a week away from the target date, I think that
>> refactoring the package names for the 1.0.0 release at the same time is a
>> stretch.
>>
>> We currently have 22 or so JIRAs and will not be able to get them all
>> into 0.13.0.
>> What do you think about the following:
>>
>> * We manage the existing scope over the rest of this week.
>> * I will post comments on some JIRAs about potentially moving them out
>> and without any movement will move them out by Friday 26th.
>> * JIRAs that I think are outside the KIPs that are driving the release or
>> that may destabilize the release I will just move.
>>
>> If I move something that is something wanted by you, please feel free to
>> add it back, comment or raise discussion on this thread.
>>
>> I also propose that we branch for 0.13.0 on Monday 5/29th and work toward
>> getting the rest of the required issues in and an RC by the 31st or by end
>> of the week. Once we release 0.13.0, we should refactor master for the
>> 1.0.0 release - concentrate on closing down any fallout from package name
>> changes and do an immediate 1.0.0 release.
>>
>> Thoughts?
>>
>> thanks,
>>
>> --larry
>>
>>
>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More 
>> wrote:
>>
>>> Sounds great !
>>>
>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay  wrote:
>>>
>>> > That sounds reasonable to me.
>>> > I was hoping to get as many of the patches available and important bugs
>>> > fixed before the split as well.
>>> > Minimizing the double commits/patches is definitely in our interest.
>>> >
>>> > At the same time, we need to have enough time to spend on refactoring
>>> as
>>> > well.
>>> > I'm thinking that May 15th may be a good branch point - giving us 2
>>> weeks
>>> > to concentrate on repackaging and adapter classes.
>>> >
>>> >
>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More 
>>> > wrote:
>>> >
>>> > > Oh, I guess it depends on when we split, I was planning on taking up
>>> the
>>> > > new feature (mentioned in earlier email).
>>> > > If we decide to go for the feature I was hoping to get it in sooner
>>> > (before
>>> > > the split) if possible.
>>> > >
>>> > >
>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay 
>>> wrote:
>>> > >
>>> > > > Actually, I meant 5/31 for a release date.
>>> > > > You think that is too early for a repackaged and narrowly scoped
>>> 1.0.0?
>>> > > >
>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
>>> moresand...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > Great, thanks Larry for starting the discussion and the KIP !
>>> > > > >
>>> > > > > May 31st target date sounds good, just to be sure, this date is
>>> when
>>> > we
>>> > > > > split 0.13 right ?
>>> > > > >
>>> > > > > KIP-5 looks good, I will try to see whether I can find any
>>> extended
>>> > > > classes
>>> > > > > that might need adapter classes.
>>> > > > >
>>> > > > > Best,
>>> > > > > Sandeep
>>> > > > >
>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay >> >
>>> > > wrote:
>>> > > > >
>>> > > > > > Forgot to add the [1] to the initial mail.
>>> > > > > >
>>> > > > > > Enjoy...
>>> > > > > >
>>> > > > > > 1.
>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
>>> > > > > > com%3E
>>> > > > > >
>>> > > > > >
>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
>>> lmc...@apache.org>
>>> > > > wrote:
>>> > > > > >
>>> > > > > > > All -
>>> > > > > > >
>>> > > > > > > After many recent distractions, I would like to start the
>>> scoping
>>> > > and
>>> > > > > > > planning for what will likely be our 1.0.0 release.
>>> > > > > > >
>>> > > > > > > As discussed in [1], we will begin to repackaging/refactor
>>> master
>>> > > > after
>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0 if
>>> the
>>> > work
>>> > > > on
>>> > > > > > > repackaging master doesn'

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

All -

As we targeted a 5/31 date for the release of 0.13.0, I think we need to
look at managing the current scope for 0.13.0 as well as the plan for a
1.0.0 again.
Since we are just a week away from the target date, I think that
refactoring the package names for the 1.0.0 release at the same time is a
stretch.

We currently have 22 or so JIRAs and will not be able to get them all into
0.13.0.
What do you think about the following:

* We manage the existing scope over the rest of this week.
* I will post comments on some JIRAs about potentially moving them out and
without any movement will move them out by Friday 26th.
* JIRAs that I think are outside the KIPs that are driving the release or
that may destabilize the release I will just move.

If I move something that is something wanted by you, please feel free to
add it back, comment or raise discussion on this thread.

I also propose that we branch for 0.13.0 on Monday 5/29th and work toward
getting the rest of the required issues in and an RC by the 31st or by end
of the week. Once we release 0.13.0, we should refactor master for the
1.0.0 release - concentrate on closing down any fallout from package name
changes and do an immediate 1.0.0 release.

Thoughts?

thanks,

--larry


On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More  wrote:

> Sounds great !
>
> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay  wrote:
>
> > That sounds reasonable to me.
> > I was hoping to get as many of the patches available and important bugs
> > fixed before the split as well.
> > Minimizing the double commits/patches is definitely in our interest.
> >
> > At the same time, we need to have enough time to spend on refactoring as
> > well.
> > I'm thinking that May 15th may be a good branch point - giving us 2 weeks
> > to concentrate on repackaging and adapter classes.
> >
> >
> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More 
> > wrote:
> >
> > > Oh, I guess it depends on when we split, I was planning on taking up
> the
> > > new feature (mentioned in earlier email).
> > > If we decide to go for the feature I was hoping to get it in sooner
> > (before
> > > the split) if possible.
> > >
> > >
> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay 
> wrote:
> > >
> > > > Actually, I meant 5/31 for a release date.
> > > > You think that is too early for a repackaged and narrowly scoped
> 1.0.0?
> > > >
> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
> moresand...@gmail.com>
> > > > wrote:
> > > >
> > > > > Great, thanks Larry for starting the discussion and the KIP !
> > > > >
> > > > > May 31st target date sounds good, just to be sure, this date is
> when
> > we
> > > > > split 0.13 right ?
> > > > >
> > > > > KIP-5 looks good, I will try to see whether I can find any extended
> > > > classes
> > > > > that might need adapter classes.
> > > > >
> > > > > Best,
> > > > > Sandeep
> > > > >
> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay 
> > > wrote:
> > > > >
> > > > > > Forgot to add the [1] to the initial mail.
> > > > > >
> > > > > > Enjoy...
> > > > > >
> > > > > > 1.
> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> > > > > rFEHJG6G5sB4Q%40mail.gmail.
> > > > > > com%3E
> > > > > >
> > > > > >
> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay  >
> > > > wrote:
> > > > > >
> > > > > > > All -
> > > > > > >
> > > > > > > After many recent distractions, I would like to start the
> scoping
> > > and
> > > > > > > planning for what will likely be our 1.0.0 release.
> > > > > > >
> > > > > > > As discussed in [1], we will begin to repackaging/refactor
> master
> > > > after
> > > > > > > branching for an 0.13.0 release and only release 0.13.0 if the
> > work
> > > > on
> > > > > > > repackaging master doesn't seem like it will make whatever date
> > we
> > > > > chose
> > > > > > > for the release.
> > > > > > >
> > > > > > > That said, I would like to limit scope to only those new
> features
> > > and
> > > > > bug
> > > > > > > fixes that are absolutely necessary or low risk for breaking
> > > backward
> > > > > > > compatibility.
> > > > > > >
> > > > > > > I propose that the following is needed:
> > > > > > >
> > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work
> > > > > required
> > > > > > > for the 1.0.0 release
> > > > > > > * Determine the existing JIRAs and patches that must/can be in
> > the
> > > > > > release
> > > > > > > but try and defer as many as possible
> > > > > > > * Determine required improvements - I have a few security
> related
> > > > > > > improvements in mind
> > > > > > > * Write up KIPs for features that involve architectural and/or
> > > > > strategic
> > > > > > > feature details
> > > > > > > * Determine when to branch for 0.13.0 and take on double
> commits
> > > for
> > > > > > 1.0.0
> > > > > > > parity
> > > > > > > * Agree on a target release date
> > > > > > >
> > > > > > > My initial thought is to target May 31st a

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[Sandeep More]

Sounds great !

On Thu, Apr 27, 2017 at 12:32 PM, larry mccay  wrote:

> That sounds reasonable to me.
> I was hoping to get as many of the patches available and important bugs
> fixed before the split as well.
> Minimizing the double commits/patches is definitely in our interest.
>
> At the same time, we need to have enough time to spend on refactoring as
> well.
> I'm thinking that May 15th may be a good branch point - giving us 2 weeks
> to concentrate on repackaging and adapter classes.
>
>
> On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More 
> wrote:
>
> > Oh, I guess it depends on when we split, I was planning on taking up the
> > new feature (mentioned in earlier email).
> > If we decide to go for the feature I was hoping to get it in sooner
> (before
> > the split) if possible.
> >
> >
> > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay  wrote:
> >
> > > Actually, I meant 5/31 for a release date.
> > > You think that is too early for a repackaged and narrowly scoped 1.0.0?
> > >
> > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More 
> > > wrote:
> > >
> > > > Great, thanks Larry for starting the discussion and the KIP !
> > > >
> > > > May 31st target date sounds good, just to be sure, this date is when
> we
> > > > split 0.13 right ?
> > > >
> > > > KIP-5 looks good, I will try to see whether I can find any extended
> > > classes
> > > > that might need adapter classes.
> > > >
> > > > Best,
> > > > Sandeep
> > > >
> > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay 
> > wrote:
> > > >
> > > > > Forgot to add the [1] to the initial mail.
> > > > >
> > > > > Enjoy...
> > > > >
> > > > > 1.
> > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> > > > rFEHJG6G5sB4Q%40mail.gmail.
> > > > > com%3E
> > > > >
> > > > >
> > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay 
> > > wrote:
> > > > >
> > > > > > All -
> > > > > >
> > > > > > After many recent distractions, I would like to start the scoping
> > and
> > > > > > planning for what will likely be our 1.0.0 release.
> > > > > >
> > > > > > As discussed in [1], we will begin to repackaging/refactor master
> > > after
> > > > > > branching for an 0.13.0 release and only release 0.13.0 if the
> work
> > > on
> > > > > > repackaging master doesn't seem like it will make whatever date
> we
> > > > chose
> > > > > > for the release.
> > > > > >
> > > > > > That said, I would like to limit scope to only those new features
> > and
> > > > bug
> > > > > > fixes that are absolutely necessary or low risk for breaking
> > backward
> > > > > > compatibility.
> > > > > >
> > > > > > I propose that the following is needed:
> > > > > >
> > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work
> > > > required
> > > > > > for the 1.0.0 release
> > > > > > * Determine the existing JIRAs and patches that must/can be in
> the
> > > > > release
> > > > > > but try and defer as many as possible
> > > > > > * Determine required improvements - I have a few security related
> > > > > > improvements in mind
> > > > > > * Write up KIPs for features that involve architectural and/or
> > > > strategic
> > > > > > feature details
> > > > > > * Determine when to branch for 0.13.0 and take on double commits
> > for
> > > > > 1.0.0
> > > > > > parity
> > > > > > * Agree on a target release date
> > > > > >
> > > > > > My initial thought is to target May 31st as the release date.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > --larry
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

That sounds reasonable to me.
I was hoping to get as many of the patches available and important bugs
fixed before the split as well.
Minimizing the double commits/patches is definitely in our interest.

At the same time, we need to have enough time to spend on refactoring as
well.
I'm thinking that May 15th may be a good branch point - giving us 2 weeks
to concentrate on repackaging and adapter classes.


On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More 
wrote:

> Oh, I guess it depends on when we split, I was planning on taking up the
> new feature (mentioned in earlier email).
> If we decide to go for the feature I was hoping to get it in sooner (before
> the split) if possible.
>
>
> On Thu, Apr 27, 2017 at 11:53 AM, larry mccay  wrote:
>
> > Actually, I meant 5/31 for a release date.
> > You think that is too early for a repackaged and narrowly scoped 1.0.0?
> >
> > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More 
> > wrote:
> >
> > > Great, thanks Larry for starting the discussion and the KIP !
> > >
> > > May 31st target date sounds good, just to be sure, this date is when we
> > > split 0.13 right ?
> > >
> > > KIP-5 looks good, I will try to see whether I can find any extended
> > classes
> > > that might need adapter classes.
> > >
> > > Best,
> > > Sandeep
> > >
> > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay 
> wrote:
> > >
> > > > Forgot to add the [1] to the initial mail.
> > > >
> > > > Enjoy...
> > > >
> > > > 1.
> > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> > > rFEHJG6G5sB4Q%40mail.gmail.
> > > > com%3E
> > > >
> > > >
> > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay 
> > wrote:
> > > >
> > > > > All -
> > > > >
> > > > > After many recent distractions, I would like to start the scoping
> and
> > > > > planning for what will likely be our 1.0.0 release.
> > > > >
> > > > > As discussed in [1], we will begin to repackaging/refactor master
> > after
> > > > > branching for an 0.13.0 release and only release 0.13.0 if the work
> > on
> > > > > repackaging master doesn't seem like it will make whatever date we
> > > chose
> > > > > for the release.
> > > > >
> > > > > That said, I would like to limit scope to only those new features
> and
> > > bug
> > > > > fixes that are absolutely necessary or low risk for breaking
> backward
> > > > > compatibility.
> > > > >
> > > > > I propose that the following is needed:
> > > > >
> > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work
> > > required
> > > > > for the 1.0.0 release
> > > > > * Determine the existing JIRAs and patches that must/can be in the
> > > > release
> > > > > but try and defer as many as possible
> > > > > * Determine required improvements - I have a few security related
> > > > > improvements in mind
> > > > > * Write up KIPs for features that involve architectural and/or
> > > strategic
> > > > > feature details
> > > > > * Determine when to branch for 0.13.0 and take on double commits
> for
> > > > 1.0.0
> > > > > parity
> > > > > * Agree on a target release date
> > > > >
> > > > > My initial thought is to target May 31st as the release date.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --larry
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[Sandeep More]

Oh, I guess it depends on when we split, I was planning on taking up the
new feature (mentioned in earlier email).
If we decide to go for the feature I was hoping to get it in sooner (before
the split) if possible.


On Thu, Apr 27, 2017 at 11:53 AM, larry mccay  wrote:

> Actually, I meant 5/31 for a release date.
> You think that is too early for a repackaged and narrowly scoped 1.0.0?
>
> On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More 
> wrote:
>
> > Great, thanks Larry for starting the discussion and the KIP !
> >
> > May 31st target date sounds good, just to be sure, this date is when we
> > split 0.13 right ?
> >
> > KIP-5 looks good, I will try to see whether I can find any extended
> classes
> > that might need adapter classes.
> >
> > Best,
> > Sandeep
> >
> > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay  wrote:
> >
> > > Forgot to add the [1] to the initial mail.
> > >
> > > Enjoy...
> > >
> > > 1.
> > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> > rFEHJG6G5sB4Q%40mail.gmail.
> > > com%3E
> > >
> > >
> > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay 
> wrote:
> > >
> > > > All -
> > > >
> > > > After many recent distractions, I would like to start the scoping and
> > > > planning for what will likely be our 1.0.0 release.
> > > >
> > > > As discussed in [1], we will begin to repackaging/refactor master
> after
> > > > branching for an 0.13.0 release and only release 0.13.0 if the work
> on
> > > > repackaging master doesn't seem like it will make whatever date we
> > chose
> > > > for the release.
> > > >
> > > > That said, I would like to limit scope to only those new features and
> > bug
> > > > fixes that are absolutely necessary or low risk for breaking backward
> > > > compatibility.
> > > >
> > > > I propose that the following is needed:
> > > >
> > > > * A KIP (KIP-5) be created for the repackaging/refactoring work
> > required
> > > > for the 1.0.0 release
> > > > * Determine the existing JIRAs and patches that must/can be in the
> > > release
> > > > but try and defer as many as possible
> > > > * Determine required improvements - I have a few security related
> > > > improvements in mind
> > > > * Write up KIPs for features that involve architectural and/or
> > strategic
> > > > feature details
> > > > * Determine when to branch for 0.13.0 and take on double commits for
> > > 1.0.0
> > > > parity
> > > > * Agree on a target release date
> > > >
> > > > My initial thought is to target May 31st as the release date.
> > > >
> > > > Thoughts?
> > > >
> > > > --larry
> > > >
> > >
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

Actually, I meant 5/31 for a release date.
You think that is too early for a repackaged and narrowly scoped 1.0.0?

On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More 
wrote:

> Great, thanks Larry for starting the discussion and the KIP !
>
> May 31st target date sounds good, just to be sure, this date is when we
> split 0.13 right ?
>
> KIP-5 looks good, I will try to see whether I can find any extended classes
> that might need adapter classes.
>
> Best,
> Sandeep
>
> On Thu, Apr 27, 2017 at 11:35 AM, larry mccay  wrote:
>
> > Forgot to add the [1] to the initial mail.
> >
> > Enjoy...
> >
> > 1.
> > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> rFEHJG6G5sB4Q%40mail.gmail.
> > com%3E
> >
> >
> > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay  wrote:
> >
> > > All -
> > >
> > > After many recent distractions, I would like to start the scoping and
> > > planning for what will likely be our 1.0.0 release.
> > >
> > > As discussed in [1], we will begin to repackaging/refactor master after
> > > branching for an 0.13.0 release and only release 0.13.0 if the work on
> > > repackaging master doesn't seem like it will make whatever date we
> chose
> > > for the release.
> > >
> > > That said, I would like to limit scope to only those new features and
> bug
> > > fixes that are absolutely necessary or low risk for breaking backward
> > > compatibility.
> > >
> > > I propose that the following is needed:
> > >
> > > * A KIP (KIP-5) be created for the repackaging/refactoring work
> required
> > > for the 1.0.0 release
> > > * Determine the existing JIRAs and patches that must/can be in the
> > release
> > > but try and defer as many as possible
> > > * Determine required improvements - I have a few security related
> > > improvements in mind
> > > * Write up KIPs for features that involve architectural and/or
> strategic
> > > feature details
> > > * Determine when to branch for 0.13.0 and take on double commits for
> > 1.0.0
> > > parity
> > > * Agree on a target release date
> > >
> > > My initial thought is to target May 31st as the release date.
> > >
> > > Thoughts?
> > >
> > > --larry
> > >
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[Sandeep More]

Great, thanks Larry for starting the discussion and the KIP !

May 31st target date sounds good, just to be sure, this date is when we
split 0.13 right ?

KIP-5 looks good, I will try to see whether I can find any extended classes
that might need adapter classes.

Best,
Sandeep

On Thu, Apr 27, 2017 at 11:35 AM, larry mccay  wrote:

> Forgot to add the [1] to the initial mail.
>
> Enjoy...
>
> 1.
> http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-rFEHJG6G5sB4Q%40mail.gmail.
> com%3E
>
>
> On Wed, Apr 26, 2017 at 12:45 PM, larry mccay  wrote:
>
> > All -
> >
> > After many recent distractions, I would like to start the scoping and
> > planning for what will likely be our 1.0.0 release.
> >
> > As discussed in [1], we will begin to repackaging/refactor master after
> > branching for an 0.13.0 release and only release 0.13.0 if the work on
> > repackaging master doesn't seem like it will make whatever date we chose
> > for the release.
> >
> > That said, I would like to limit scope to only those new features and bug
> > fixes that are absolutely necessary or low risk for breaking backward
> > compatibility.
> >
> > I propose that the following is needed:
> >
> > * A KIP (KIP-5) be created for the repackaging/refactoring work required
> > for the 1.0.0 release
> > * Determine the existing JIRAs and patches that must/can be in the
> release
> > but try and defer as many as possible
> > * Determine required improvements - I have a few security related
> > improvements in mind
> > * Write up KIPs for features that involve architectural and/or strategic
> > feature details
> > * Determine when to branch for 0.13.0 and take on double commits for
> 1.0.0
> > parity
> > * Agree on a target release date
> >
> > My initial thought is to target May 31st as the release date.
> >
> > Thoughts?
> >
> > --larry
> >
>

Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release

[larry mccay]

Forgot to add the [1] to the initial mail.

Enjoy...

1.
http://mail-archives.apache.org/mod_mbox/knox-dev/201704.mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-rFEHJG6G5sB4Q%40mail.gmail.com%3E


On Wed, Apr 26, 2017 at 12:45 PM, larry mccay  wrote:

> All -
>
> After many recent distractions, I would like to start the scoping and
> planning for what will likely be our 1.0.0 release.
>
> As discussed in [1], we will begin to repackaging/refactor master after
> branching for an 0.13.0 release and only release 0.13.0 if the work on
> repackaging master doesn't seem like it will make whatever date we chose
> for the release.
>
> That said, I would like to limit scope to only those new features and bug
> fixes that are absolutely necessary or low risk for breaking backward
> compatibility.
>
> I propose that the following is needed:
>
> * A KIP (KIP-5) be created for the repackaging/refactoring work required
> for the 1.0.0 release
> * Determine the existing JIRAs and patches that must/can be in the release
> but try and defer as many as possible
> * Determine required improvements - I have a few security related
> improvements in mind
> * Write up KIPs for features that involve architectural and/or strategic
> feature details
> * Determine when to branch for 0.13.0 and take on double commits for 1.0.0
> parity
> * Agree on a target release date
>
> My initial thought is to target May 31st as the release date.
>
> Thoughts?
>
> --larry
>