>>>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.
Makes sense to me. >>> Before we do anything someone should spend some time looking at >>> what folks like Hadoop are doing (the process). I'm adding few details which I observed in the Hadoop project. Perhaps, Chris can correct/edit more about this. 1) PMC proposes for a feature branch in JIRA, then will decide for a feature branch on any specific branch or trunk. In Hadoop, afaik most of the features branched out from trunk. But I think if needed the new branch can be created from a specific branch. 2) In git, creates a new branch named with JIRA name. (For simplicity please assume feature branch is created from trunk). 3) There is a branch committer option, will allow new guys as branch committer only for that branch scope. 4) Periodically merge the trunk changes to the feature branch in order to keep changes minimal when compared to the trunk. 5) All jira sub tasks committed to this feature branch. 6) Hadoop project has done changes to trigger the pre-commit build on that branch code and get the QA report. For example, upload a patch by appending the branch name to the patch name. Assume feature jira name is ZOOKEEPER-2125, then will create a branch called ZOOKEEPER-2125. Again assume, my jira sub-task is ZOOKEEPER-3000, now will attach the patch named "ZOOKEEPER-3000-ZOOKEEPER-2125.patch", then Jenkins will pick up this patch and run against the branch code. 7) When branch maintainer feels, its ready for merge, they will call for vote. It requires 3 PMC votes for merging the branch to trunk. Regards, Rakesh On Mon, Jul 18, 2016 at 10:55 PM, Patrick Hunt <[email protected]> wrote: > 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 > > > >>>>> > > > >>>>> > > > >>> > > > >>> > > > >> > > > > > > > > >
