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 <https://issues.apache.org/jira/browse/KNOX-979>[image: Bug] <https://issues.apache.org/jira/browse/KNOX-979> KNOX-979 <https://issues.apache.org/jira/browse/KNOX-979> Documentation for Atlas UI & Atlas Rest Api via Knox Proxy <https://issues.apache.org/jira/browse/KNOX-979> Nixon Rodrigues <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues> Nixon Rodrigues <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues> [image: Major] PATCH AVAILABLE *Unresolved* 06/Jul/17 02/Aug/17 <https://issues.apache.org/jira/rest/api/1.0/issues/13085193/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin> <https://issues.apache.org/jira/browse/KNOX-976>[image: Task] <https://issues.apache.org/jira/browse/KNOX-976> KNOX-976 <https://issues.apache.org/jira/browse/KNOX-976> Add Jupyter Kernel Gateway Service Definitions <https://issues.apache.org/jira/browse/KNOX-976> Jesus Alvarez <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jesus.alv> Jesus Alvarez <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jesus.alv> [image: Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 19/Jul/17 <https://issues.apache.org/jira/rest/api/1.0/issues/13081856/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin> <https://issues.apache.org/jira/browse/KNOX-972>[image: Bug] <https://issues.apache.org/jira/browse/KNOX-972> KNOX-972 <https://issues.apache.org/jira/browse/KNOX-972> Update Hbase UI service <https://issues.apache.org/jira/browse/KNOX-972> Jeffrey E Rodriguez <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97> Jeffrey E Rodriguez <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97> [image: Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 03/Aug/17 23/Jun/17 <https://issues.apache.org/jira/rest/api/1.0/issues/13081847/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin> <https://issues.apache.org/jira/browse/KNOX-789>[image: New Feature] <https://issues.apache.org/jira/browse/KNOX-789> KNOX-789 <https://issues.apache.org/jira/browse/KNOX-789> Apache Atlas REST API support <https://issues.apache.org/jira/browse/KNOX-789> Nixon Rodrigues <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues> Jeffrey E Rodriguez <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97> [image: Major] REOPENED *Unresolved* 15/Nov/16 03/Aug/17 Actions <https://issues.apache.org/jira/rest/api/1.0/issues/13020977/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin> Thanks, --larry On Mon, Jun 26, 2017 at 12:35 PM, Jeffrey Rodriguez <jeffrey...@gmail.com> 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 <lmc...@apache.org> 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 <lmc...@apache.org> 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 <moresand...@gmail.com> > > > wrote: > > > > > >> Ah ! got it. > > >> > > >> > > >> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lmc...@apache.org> > 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 <moresand...@gmail.com > > > > >>> 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 <lmc...@apache.org> > > 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 < > moresand...@gmail.com > > > > > >>>>> wrote: > > >>>>> > > >>>>>> Sounds great ! > > >>>>>> > > >>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lmc...@apache.org> > > >>>>>> 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 < > > lmc...@apache.org> > > >>>>>> 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 < > > >>>>>> lmc...@apache.org> > > >>>>>> > > 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'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 > > >>>>>> > > > > > > > > >>>>>> > > > > > > > >>>>>> > > > > > > >>>>>> > > > > > >>>>>> > > > > >>>>>> > > > >>>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > >
