We are in very similar situation. We have bugs for 4.2.x that are more urgent than what we currently have for 4.3. Including bugs where we already know we will be doing the 4.2.z backport.
Martin On Fri, Dec 1, 2017 at 9:08 PM, Dan Kenigsberg <dan...@redhat.com> wrote: > On Fri, Dec 1, 2017 at 2:06 PM, Greg Sheremeta <gsher...@redhat.com> wrote: >> >> On Fri, Dec 1, 2017 at 3:25 AM, Dan Kenigsberg <dan...@redhat.com> wrote: >>> >>> On Fri, Dec 1, 2017 at 3:18 AM, Greg Sheremeta <gsher...@redhat.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> I have some 4.2.1 bugs I want to start working on, but I don't want them >>>> getting into 4.2.0 GA. What should I do? >>>> >>>> Best wishes, >>>> Greg >>> >>> >>> You can work on them all right, but until we have an rc branch, you should >>> not have them merged. >>> I believe that an rc branch would be created after rc1 is built (which is >>> now delayed for the 4th day). >>> >> >> Ok, makes sense. But even after the rc is built and safe, there's always a >> chance of us needing another rc before 4.2 GA. So isn't it the case that >> nothing for 4.2.1 should be merged until the GA branch is created (if >> there's such a thing, or is that the rc branch you refer to)? >> >> I know this was discussed in a meeting, but I guess I'm a proponent of >> branching 4.2 off master completely at this point. We (UX team) have some >> 4.3 items I think we could start on, too. >> >> Leaving a bunch of patches sitting in gerrit introduces risks of them not >> working when they all get rebased, and we're also missing out on OST. >> > > People in my team have plenty of 4.2 bugs to work on (17 bugs, few > RFEs) and no urgent 4.3 tasks, so for us, branching out 4.2 means > double the backports. > > However, we have 0 bugs for 4.2.0, so I am a proponent of branching > out 4.2.0-rc now (but that may mean a lot of headache for CI team). > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
