[Cluster-devel] Orphaned bits in CVS HEAD.

[Cluster-devel] Orphaned bits in CVS HEAD.

[Fabio Massimo Di Nitto]

Hi guys,

not too long ago we discussed about removing unused bits from CVS HEAD tree.
Some cleaning has been already done.

These are files/dirs that are still in the tree but somewhat unused (yes some of
them have been discussed over and over but I am readding them here just to keep
a full overview):

clumon/ - this is now in conga and didn't receive any update in CVS HEAD for a
long time. The core code is the same as in RHEL5 branch. Like we agreed for
cs-deploy-tools, I think this can go from HEAD and live in RHEL5 for historical
reasons.

cmirror/Makefile - the entire userland tree is empty and it has been maintained
only in specific RHEL branches.

cmirror-kernel/* - it has been maintained only in specific RHEL branches. The
version in HEAD did not received a commit in months. The tree will move to
another kernel tree or catch up (or so I am told).

csnap*/ are in a similar situation as cmirror*/

fence/agents/apc/ has fence_apc.pl, fence_apc_snmp.py, powernet369.mib and
README files that looks obsoleted to me. If they are still required we should
probably make them available to the user in an easy way.

fence/agents/drac/test_drac.sh is this file still used for testing or is it
obsoleted?

gfs-kernel/patches/lock_dlm-include.patch seems unrequired.

gfs2/debug is not build or updated. I asked about it a few days back but no
comment so far. If it's still useful, please let me know and I will update the
relevant Makefiles to build and make it available.

gfs and gfs2 tools/ have decipher_lockstate_dump and parse_lockdump scripts.
Should we ship them or is it best to keep them only internal? on the note..
parse_lockdump is the same in both dirs.

Cheers
Fabio

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

[Cluster-devel] Orphaned bits in CVS HEAD.

[Ryan McCabe]

On Wed, Aug 29, 2007 at 07:25:06AM +0200, Fabio Massimo Di Nitto wrote:
> clumon/ - this is now in conga and didn't receive any update in CVS HEAD for a
> long time. The core code is the same as in RHEL5 branch. Like we agreed for
> cs-deploy-tools, I think this can go from HEAD and live in RHEL5 for historical
> reasons.

This one can go.

> fence/agents/apc/ has fence_apc.pl, fence_apc_snmp.py, powernet369.mib and
> README files that looks obsoleted to me. If they are still required we should
> probably make them available to the user in an easy way.

fence_apc_snmp.py and powernet369.mib are still used. fence_apc.pl has
been replaced by fence_apc.py, but I think it's still worth keeping
around for now.



Ryan 

[Cluster-devel] Orphaned bits in CVS HEAD.

[Fabio M. Di Nitto]

Ryan McCabe wrote:
> On Wed, Aug 29, 2007 at 07:25:06AM +0200, Fabio Massimo Di Nitto wrote:
>> clumon/ - this is now in conga and didn't receive any update in CVS HEAD for a
>> long time. The core code is the same as in RHEL5 branch. Like we agreed for
>> cs-deploy-tools, I think this can go from HEAD and live in RHEL5 for historical
>> reasons.
> 
> This one can go.

Ok added in my list of things to remove once I am back home.

> 
>> fence/agents/apc/ has fence_apc.pl, fence_apc_snmp.py, powernet369.mib and
>> README files that looks obsoleted to me. If they are still required we should
>> probably make them available to the user in an easy way.
> 
> fence_apc_snmp.py and powernet369.mib are still used. fence_apc.pl has
> been replaced by fence_apc.py, but I think it's still worth keeping
> around for now.

Is it worth shipping the apc_snmp + powernet369.mib?

I will keep the .pl around and add a comment that has been replaced and
aging there till we declare it dead.

Cheers
Fabio

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

[Cluster-devel] Orphaned bits in CVS HEAD.

[Ryan McCabe]

On Wed, Aug 29, 2007 at 08:31:23PM +0200, Fabio M. Di Nitto wrote:
> Is it worth shipping the apc_snmp + powernet369.mib?
> 
> I will keep the .pl around and add a comment that has been replaced and
> aging there till we declare it dead.

I thought this agent was being shipped. Maybe Jim would know the
details.


Ryan