[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] STABLE2 cluster branch



On Mon, 3 Mar 2008, Steven Dake wrote:

On Mon, 2008-03-03 at 09:10 -0600, David Teigland wrote:
On Sat, Mar 01, 2008 at 02:52:05PM -0700, Steven Dake wrote:
This is reasonable but requires having quite a bit of conditional
compilation in cman and other tools.  I don't know if anyone is working
on this, but I'd imagine maintenance of such a scheme would be
complicated since the trunk of whitetank is about to rev into tigh speed
modification requiring different dependencies of the gfs userland.

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.


I agree we need to release stable2 with the current whitetank.

While I would like to have corosync enabled for F9, it wont be ready in
time for that distribution.  The corosync tree hasn't yet emerged so
targeting f9 is a bit premature.

Unfortunately this creates quite a bit more work WRT ifdeffing of the
code to support either corosync or whitetank.  I don't mind helping with
the rest of the infrastructure conversion to corosync in the trunk of
the gfs tree, but keeping stable2 operational with both sounds like a
lot of difficult work.

Indeed, but diff will help us here. We have the exact history of patches that were required to switch from whitetank to trunk. We just need to rediff them manually with --ifdef= and reapply to stable2.

If the distributions really need it, however, it is something we should
address.

Well some distributions do actually ship trunk because of the several endianess and alignment bug fixes that are not in whitetank.

 I believe really what we need is a stable 3 which is branched
from trunk to work with corosync once corosync and trunk have met some
level of capabilities (like it compiles, works, and passes heavy stress
testing).  But maybe this creating of stable3 is more work then making
stable2 work with both openais and corosync.

Given the branch management history of this project, i don't believe in a stable3 branch. stable2 is already out of sync with bug fixes and it's just been created.

Very few developers, and it's just a matter of fact, remember to push fixes to all branches. No complain involved. it's just how it used to work in the past :)))

In my opinion though, a stable branch shouldn't add features or entirely
new foundations for the code such as a new infrastructure.  So I'm not
sure why to call it stable2 if in fact it is a "stable trunk" :)

You have point, but i think stable-trunk is what we really need.

if we look at the branch from another perspective, we will keep updating the kernel modules to run with .25 and future kernel releases. I don't see why it should be any different for openais.

The stack has clearly a bunch of very strong depends that need to be addressed.

Fabio

--
I'm going to make him an offer he can't refuse.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]