> >> 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? Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ 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
