From: Steven Dake <sdake@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] STABLE2 cluster branch
Date: Sat, 01 Mar 2008 14:52:05 -0700 [thread overview]
Message-ID: <1204408326.31162.25.camel@balance> (raw)
In-Reply-To: <Pine.LNX.4.64.0803011725360.5782@trider-g7>
On Sat, 2008-03-01 at 17:31 +0100, Fabio M. Di Nitto wrote:
> From:
> Fabio M. Di Nitto
> <fabbione@ubuntu.com>
> To:
> Steven Dake <sdake@redhat.com>
> Cc:
> Fabio M. Di Nitto
> <fabbione@ubuntu.com>, David
> Teigland <teigland@redhat.com>,
> cluster-devel at redhat.com
> Subject:
> Re: [Cluster-devel] STABLE2 cluster
> branch
> Date:
> Sat, 1 Mar 2008 17:31:22 +0100
> (CET) (09:31 MST)
>
>
> On Sat, 1 Mar 2008, Steven Dake wrote:
>
> > On Sat, 2008-03-01 at 07:13 +0100, Fabio M. Di Nitto wrote:
> >> Hi guys,
> >>
> >> On Fri, 22 Feb 2008, David Teigland wrote:
> >>
> >>> I've created a new STABLE2 branch from master in the new
> cluster.git.
> >>
> >> thanks for this work...
> >>
> >>> The point of STABLE2 is:
> >>>
> >>> - build/run with the current stable release of openais, (now
> 0.80.3)
> >>
> >> I think i would really like to be able to detect this at build
> time. I
> >> know as a project we don't usually add #ifdef version > 1.0 kind of
> things
> >> but some distributions already have openais 0.82 around and a
> downgrade to
> >> follow the stable2 branch could be complex.
> >>
> >> I don't see creating another branch is the right solution as it
> will
> >> involve the extra overhead for it.
> >>
> >>> I think we're in good shape already for the kernel, but some work
> is
> >>> needed for compatibility with openais 0.80.3.
> >>
> >> Is anybody actually working on this?
> >>
> >
> > I believe the answer is no but I am not sure if Dave or Chrissie are
> > working on this effort.
> >
> > I continue to maintain and work on the stable branch of openais
> > (whitetank 0.80.3), but I don't know of the efforts Dave is talking
> > about or even what was branched to create stable2.
>
> > I assume it is the
> > current trunk of the gfs userland tree. In this case, the current
> > trunk(stable2) is meant to work against the trunk of openais.
>
> STABLE2 was branched from trunk with the idea in mind to revert the
> minimal amount of changes in the cluster stack to work with openais
> whitetank.
>
> >
> > _No_ new features are going into whitetank at all so whatever is in
> > stable 2 must be modified to work with the whitetank branch.
>
> we already know this. nobody is asking you to change anything here.
> It's
> the branch in cluster that needs to change.
>
> > The "trunk" of openais/corosync will work with the trunk of the git
> > repo. This is the only effort underway now involving openais.
>
> nothing new here either.
>
> >
> > I __am not creating new branches__ of openais to work specifically
> with
> > stable 2 or backporting any feature additions that are currently in
> > trunk. The only porting that will take place is forward ports of
> bug
> > fixes in the whitetank branch that are not in the trunk.
>
> I think you misunderstood completely my email. Nobody is asking you
> to
> change anything in openais to handle the stable2 branch.
>
> The original plan for the STABLE2 branch is to work with openais
> whitetank
> stable branch.
>
> What i did ask was to change this original plan to make it so that
> STABLE2
> branch can work with both whitetank and openais trunk by detecting
> the
> openais version at build time.
>
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.
Regards
-steve
> > Finally whitetank is frozen to feature additions that are not
> critical
> > to user requirements. Only bug fixes go into whitetank. Our full
> > commit policy WRT various branches can be found here:
> >
> > http://www.openais.org/doku.php?id=dev:commit_policy
>
> nothing new here either..
>
> Fabio
>
> --
> I'm going to make him an offer he can't refuse.
next prev parent reply other threads:[~2008-03-01 21:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 20:48 [Cluster-devel] STABLE2 cluster branch David Teigland
2008-03-01 6:13 ` Fabio M. Di Nitto
2008-03-01 8:33 ` Steven Dake
2008-03-01 16:31 ` Fabio M. Di Nitto
2008-03-01 21:52 ` Steven Dake [this message]
2008-03-03 15:10 ` David Teigland
2008-03-03 16:10 ` Fabio M. Di Nitto
2008-03-03 16:30 ` David Teigland
2008-03-04 13:39 ` Christine Caulfield
2008-03-04 19:59 ` Steven Dake
2008-03-05 11:39 ` Christine Caulfield
2008-03-05 16:23 ` Christine Caulfield
2008-03-03 17:07 ` Steven Dake
2008-03-03 17:48 ` David Teigland
2008-03-03 18:31 ` Fabio M. Di Nitto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1204408326.31162.25.camel@balance \
--to=sdake@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.