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 >>>>> > > > > > > >>>>> > > > > > >>>>> > > > > >>>>> > > > >>>>> > > >>>>> > >>>>> >>>> >>>> >>> >> >
