Changing the bylaws is pretty significant, and would require a vote by the PMC.
Instead I'd recommend we get PMC approval to do a trial run with a single branch to start. If that's successful we can consider making it more formalized. Before we do anything someone should spend some time looking at what folks like Hadoop are doing (the process). Patrick On Mon, Jul 18, 2016 at 10:16 AM, Rakesh Radhakrishnan <[email protected]> wrote: > +1(non-binding). Its an interesting idea. I also feel, this would make the > feature development more easy and can attract more users/contributors. > > If everyone agrees to this, we could update the project bylaws including > the (1)role & responsibility of feature branch committers, (2)merging back > the feature branch changes to the mainstream (3)branch committer removal > etc. > > > Rakesh > > > > On Mon, Jul 18, 2016 at 9:51 PM, Flavio Junqueira <[email protected]> wrote: > > > That's a great idea, I'm +1. > > > > -Flavio > > > > > On 11 Jul 2016, at 21:13, Patrick Hunt <[email protected]> wrote: > > > > > > I'd like to recommend that we consider a special 3.4 branch for this. > > > (sorry I'm late to the party but I was on vacation till today, just > > back). > > > > > > We could create a 3.4+ssl branch, or something like that, and give > > special > > > permissions for non-committers to commit to the branch. People that are > > > interested in this feature but not committers. Once the folks working > on > > > this are satisfied the PMC could do a special "3.4.9+ssl" release > > artifact > > > (say just a tarball), separate from the 3.4.x line, for folks that are > > > interested to use it. This would require minimal oversight by the > > > committers. I believe other components are doing this, typically for > > > feature development before being merged back in, but it would enable > > > interested parties to get access to ssl prior to 3.5 becoming stable. > It > > > would also benefit 3.5 in the sense that anything we learn on that > branch > > > would be merged into the trunk - fixes say. > > > > > > Patrick > > > > > > On Tue, Jul 5, 2016 at 11:45 AM, Luciano Afranllie < > > [email protected] > > >> wrote: > > > > > >> Quick question, ZK-2125 depends on > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2069 and > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2072? > > >> > > >> It seems to be given the description of ZK-2063... > > >> > > >> Regards > > >> Luciano > > >> > > >> > > >> On Fri, Jul 1, 2016 at 12:20 PM, Flavio Junqueira <[email protected]> > > wrote: > > >> > > >>> I think you're talking about porting the patch of ZK-2125. I haven't > > >>> really assessed how much work it would be to backport it, but it is > > >>> possibly not hard. > > >>> > > >>> -Flavio > > >>> > > >>>> On 01 Jul 2016, at 15:54, Luciano Afranllie < > [email protected] > > > > > >>> wrote: > > >>>> > > >>>> Thanks Flavio > > >>>> > > >>>> What about back porting in our own private fork while we wait for > the > > >>> 3.5? > > >>>> I would like your help understanding how easy/difficult this may be. > > >>>> > > >>>> Regards > > >>>> Luciano > > >>>> > > >>>> On Fri, Jul 1, 2016 at 9:23 AM, Flavio Junqueira <[email protected]> > > >> wrote: > > >>>> > > >>>>> Hi Luciano, > > >>>>> > > >>>>> The 3.4 branch is stable and we are only releasing bug fixes at > this > > >>>>> point, so it is currently not an option to back port. > > >>>>> > > >>>>> We are all pretty eager to see the 3.5 branch stable, and we are in > > >> the > > >>>>> process of voting the release candidate for 3.5.2, but that's still > > >>> tagged > > >>>>> as alpha. We don't have a current plan for 3.5.3 yet, but I believe > > no > > >>> one > > >>>>> here wants to wait too long have it out. I suspect that it won't be > > >>> before > > >>>>> 3 months from now given the pace that we have been releasing, > though. > > >>>>> > > >>>>> -Flavio > > >>>>> > > >>>>> > > >>>>>> On 01 Jul 2016, at 13:07, Luciano Afranllie < > > >> [email protected]> > > >>>>> wrote: > > >>>>>> > > >>>>>> Hi there > > >>>>>> > > >>>>>> We are in the need to have SSL support in Zookeeper in order for > our > > >>>>>> solution to be FIPS complaint. > > >>>>>> > > >>>>>> Of course one option is to wait for 3.5 to be released but given > we > > >>> are a > > >>>>>> little bit time constrained we want to consider an alternative of > > >>>>>> backporting SSL support from 3.5 to 3.4 (we are using 3.4.8) > > >>>>>> > > >>>>>> Do you think this is doable? Can you please tell me the impact of > > >> doing > > >>>>>> this and if you think it is a viable alternative? We have > experience > > >>> with > > >>>>>> Java but not with ZK at development level. > > >>>>>> > > >>>>>> Of, course if you have a rough estimate about when ZK 3.5 may be > > >>> released > > >>>>>> that may help in our decision too. > > >>>>>> > > >>>>>> Regards > > >>>>>> Luciano > > >>>>> > > >>>>> > > >>> > > >>> > > >> > > > > >
