[Cluster-devel] STABLE cluster branch?!

[Marc - A. Dahlhaus [ Administration | Westermann GmbH ]]

Am Mittwoch, den 12.09.2007, 09:05 -0500 schrieb David Teigland:
> On Wed, Sep 12, 2007 at 12:12:00PM +0200, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
> > Am Dienstag, den 11.09.2007, 11:48 -0500 schrieb David Teigland:
> > > On Tue, Sep 11, 2007 at 11:04:58AM +0200, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
> > > > Hello,
> > > > 
> > > > are there any plans to merge the changes/fixes from the RHEL4
> > > > branch into STABLE? A new 1.0# release would be nice after that.
> > > 
> > > We don't have any plans to do that, but would be willing to review and
> > > commit patches to STABLE.  It's porting the STABLE kernel dirs to the
> > > recent kernel.org releases that's the biggest chore.
> > 
> > I found out that the fixes/changes from RHEL4 are also in HEAD after my
> > last post. We plan to migrate our 6TB GFS 6.1 volume to that tree. Is
> > the GFS 6.1 part in HEAD with the OpenAIS based DLM already "production
> > stable"?
> 
> Yes, HEAD is about the same as the RHEL5 branch.  HEAD follows the latest
> kernel.org kernels, but the RHEL5 branch follows the rhel5 kernel.  So,
> pick the HEAD or RHEL5 branch depending on the kind of kernel you'd like.

We use 1.04.00 at the moment and there was no glock_purge flag in it so
i checked the stable branch and found nothing. That HEAD and RHEL5 both
have the same "patchlevel" and only differ on the followed kernel
version was the reason for asking if this could be also made for RHEL4
and STABLE...

> An alternative to using HEAD is to use the cluster-2.xx.yy tarballs which
> are snapshots from HEAD at more stable points in time.  Another difficulty
> with using HEAD directly is that it sometimes (like now) requires kernel
> patches that haven't made it upstream beyond the gfs2 git tree.

We'll wait for the 2.6.23 release before we migrate to 2.01.00.

I think a separate branch which follows the last released vanilla kernel
tree for gfs2 could be useful while there is so much movement in HEAD.
Merging HEAD into that branch after each merge window on Linus tree
could minimize the needed manpower and the release of tarballs would
also require less time out of that branch. Adopters of the tarball could
get fixes from there too. Before gfs2 the STABLE branch was exactly that
or wasn't it?


Marc