On 04/24/2017 12:53 PM, Frank Filz wrote: >>>> Our proposal is this: >>>> >>>> Branch when Ganesha goes into -rc, rather than on .0 release. This >>>> allows us to modify the -rc version of Ganesha to build and work > against >>>> the then-extant versions of Ceph in the distros, and not have to worry >>>> about syncing dev cycles between Ceph and Ganesha. >>> >>> Forking at -rc makes sense for me, as we can then only land fixes there >>> and continue with regular development on next. >>> The only black spot there is that it will give Frank more work (as there >>> will have to be two merges for a few weeks), so I guess ultimately it's >>> down to him. >>> >> >> Or hand the -rc off to the next version maintainer? But yes, slightly >> more work either way. (Of course, there may not be anything to merge >> for the next -dev, at least for a while) > > Typically while we are in rc, stuff that will not go into the release under > rc is just held until we open dev again, so no double merges. > > So the remaining issue is what is the best way to converge on stable code > that will build with release versions of other packages. > > What kinds of fixups are we talking here? Can we just revert the fixups when > we open dev of the next release? >
The problem is that this will involve: 1) Reverting changes in next 2) <breaking teuthology, because those changes are missing> 3) Re-introducing those changes when the release branches. This (aside from 2, which is a problem) is only messy in our history. Daniel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
