#154 SIG Review: Storage
Opened 4 days ago by shaunm. Modified 2 days ago

This is an annual review of the Storage SIG. Please verify that all the information on the SIG is correct, and determine whether the SIG is active, winding down, or needs to be retired.

Previous review: https://git.centos.org/centos/board/issue/106

Web

https://centos.org/sigs/#storage

Storage solutions for enterprise environments, including Ceph, Gluster, NFS Ganesha, and Samba.

The Storage SIG ensures that CentOS is a suitable platform for many different storage solutions. This group ensures that all open source storage options seeking to utilize CentOS as a delivery platform have a voice in packaging, orchestration, deployment, and related work.

Info

account: sig-storage
sponsors: @devos
web: -
docs: https://sigs.centos.org/storage
repo: https://gitlab.com/CentOS/storage
bugs: https://gitlab.com/groups/CentOS/storage/-/issues
chat: -

Meetings

https://github.com/CentOS/Calendar/blob/main/meetings/storage-sig.yaml

project:  Storage SIG
project_url: http://wiki.centos.org/SpecialInterestGroup/Storage
agenda_url: https://hackmd.io/@qItv4l_CSAOOoigrY3dOGA/rkAGV6Lpr
schedule:
  - time:       '1000'
    day:        Tuesday
    irc:        centos-meeting2
    frequency:  first-tuesday
chair:  Karanbir Singh (kbsingh), Niels de Vos (ndevos), Giulio Fidente (gfidente)
description: >
    The CentOS Storage Special Interest Group (SIG) is a collection of like-minded
    individuals coming together to ensure that CentOS is a suitable platform for
    many different storage solutions. This group will ensure that all Open
    Source storage options seeking to utilize CentOS as a delivery platform have
    a voice in packaging, orchestration, deployment, and related work.
    We meet monthly on the first Tuesday of the month.

Reports


@kkeithle , shall we move the the Gluster project to an emeritus state? I doubt it will have any more releases.

@anoopcs, Samba is listed as well, but I do not know if there have been any packages published recently?

Ceph and nfs-ganesha are maintained well, thanks @kkeithle!

The meeting does not really happen anymore, time across the wold is inconvenient and only maintainers used to join. We should probably update the meeting to 1/2 yearly or so, and make an effort so that involved people can join.

@anoopcs, Samba is listed as well, but I do not know if there have been any packages published recently?

I can say that Samba is also actively maintained: https://cbs.centos.org/koji/packageinfo?packageID=7

shall we move the the Gluster project to an emeritus state? I doubt it will have any more releases.

Is emeritus a real state? Or are you asking if we should let it fade away by not building new packages for el10 and the eventual el11? Versus explicitly retiring it?

I handed off GlusterFS in Fedora to a new maintainer. I suppose at this point they could build it in EPEL if they were so inclined.

Is emeritus a real state? Or are you asking if we should let it fade away by not building new packages for el10 and the eventual el11? Versus explicitly retiring it?

Retiring would probably be the right terminology, yes. The last release was made over a year ago, maintenance has come almost to a halt. If users report an issue, it is difficult for members of the Storage SIG to help them out.

I handed off GlusterFS in Fedora to a new maintainer. I suppose at this point they could build it in EPEL if they were so inclined.

Indeed, if there is interest from someone, they could build it in EPEL. If they show a strong interest and involvement in the upstream project, they are of course also welcome to maintain the packages as part of the SIG too.

@shaunm, is there a standard practice to retire a project from a SIG? I guess we need to

  • solicit for contributors that want to take over
  • informing users
  • deprecating/retiring the packages

I handed off GlusterFS in Fedora to a new maintainer. I suppose at this point they could build it in >> EPEL if they were so inclined.

Indeed, if there is interest from someone, they could build it in EPEL. If they show a strong interest
and involvement in the upstream project, they are of course also welcome to maintain the
packages as part of the SIG too.

Yes, this theoretical someone could sign up in the SIG and keep building. But why? The original reason for having it in the SIG is now gone. (Namely that Red Hat was shipping it in "RHEL".)

IMO, if someone wants it for EL, they should ask the Fedora maintainer to build it in EPEL.

Log in to comment on this ticket.

Metadata