Steven Dake wrote: > bOn Tue, 2008-03-04 at 13:39 +0000, Christine Caulfield wrote: >> David Teigland wrote: >>> On Mon, Mar 03, 2008 at 05:10:54PM +0100, Fabio M. Di Nitto wrote: >>>>>> If we are to say this conditional compilation "only works with trunk of >>>>>> openais up to a certain point such as version 0.84" then that certain >>>>>> point becomes a "branch point" which I really do not want. What I >>>>>> prefer is that trunk of gfs userland be munged to work with the new >>>>>> corosync dependency and once that has all stabilized create a new branch >>>>>> of userland to work with the corosync 1.0 infrastructure. The complete >>>>>> software suite then would be "stable3" + "corosync 1.X" + "trunk of >>>>>> openais ais services" for the checkpoint service. >>>>> So it sounds like the next stable release of openais will be in the new >>>>> form of corosync + openais? Will Fedora 9 have whitetank or the new >>>>> corosync+openais release? >>>>> >>>>> We definately need to do a release or two of cluster-2.y.z from STABLE2 >>>>> based on openais whitetank. Then, once a stable release of >>>>> corosync+openais exists, I see sense in either: >>>>> >>>>> 1. switching STABLE2 from whitetank to the corosync+openais release >>>>> 2. supporting both whitetank and corosync in STABLE2 somehow, perhaps >>>>> dropping whitetank support after a while >>>>> >>>>> 1 would make most sense if F9 has corosync, 2 would make most sense if F9 >>>>> has whitetank. >>>> Clearly STABLE2 is running on truck and what would be corosync+openais >>>> hopefully in not too long from now. >>>> >>>> Does it make sense to roll back to whitetank and back in such short time? >>>> Let's keep in mind that if we push out stable releases into distro with >>>> the stable2+whitetank combo, i assume we will need to keep supporting it >>>> for a while before turning stable2 to support corosync. >>>> >>>> Hence my general idea of just #ifdeffing openais support in stable2 to >>>> handle both whitetank and corosync at build time (no runtime detection) >>>> and let the users/distros decide what combo they prefer. >>>> >>>> If you look at it: >>>> >>>> whitetank does not change. stable2 support will only need roll back. >>>> >>>> trunk changes in openais. our master follows openais trunk. Commit the >>>> diff into stable2. It's going to be just a bit painful in the very >>>> beginning but at the end it's a matter of a cherry pick or almost. >> It shouldn't be /toooo/ bad. The main thing that keeps cman from >> compiling against whitetank is the lack of logsys. We don't need to >> backport logsys to whitetank, just provide a compatibility API for it. >> Given that most of that is log_printf() that's not going to be very >> arduous I hope. With luck (and I haven't check this in detail) I hope it >> can be isolated to the logging.[ch] files. >> >> Chrissie >> > > When corosync 1.0 is released the entire ABI used to make plugins will > change as well as the recovery system. > > I am not backporting or making compatibility interfaces for these > things. So the code will have to be ifdefed to deal with this > condition, or a stable3 branch will have to be branched off trunk when > corosync is released.
It might be easiest to have separate files for the 'openais' and 'corosync' interfaces in that case. We'll see. Chrissie
