[Gluster-Maintainers] [gluster-packaging] glusterfs-3.10.5 released

Niels de Vos ndevos at redhat.com
Mon Aug 14 11:16:49 UTC 2017

On Mon, Aug 14, 2017 at 06:56:52AM -0400, Shyam Ranganathan wrote:
> On 08/12/2017 11:56 AM, Niels de Vos wrote:
> > On Sat, Aug 12, 2017 at 12:49:14PM +0000, Gluster Build System wrote:
> > > 
> > > 
> > > SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.10.5.tar.gz
> > > 
> > > This release is made off v3.10.5
> > 
> > Packages for the CentOS Storage SIG are available for testing. Please
> > let me know when someone tried them (even minor checks are sufficient)
> > so that I can mark them for releasing to the CentOS mirrors.
> > 
> >    # yum install centos-release-gluster310
> >    # yum --enablerepo=centos-gluster310-test install \
> >        glusterfs-server-3.10.5-1.el7
> > 
> > 
> > I never received any feedback for the 3.10.4 packages, and have now
> > tagged them for release (fingers crossed!). Once the CentOS team does a
> > new sync run, the 3.10.4 packages will be available on the mirrors.
> @Neils is there any testing of the package done by you? I am asking as (like
> last time) there is no real owner for package testing other than the package
> maintainers. As a result I do not expect anyone in the maintainers list to
> respond, unless we make this an activity for someone to own up.

When I have time, I would run some tests. It is not a given that I (can)
make time for it, and surely do not want the sole responsibility for it.

As long as nobody else tests, the packages may stay in the testing
repository indefinitely. It would be good to have a perseon (per major
release?) that is heading the testing efforts. Fedora has it automated
in their update process (Bodhi w/ karma), there is no such thing for
CentOS SIGs. I do not know how it works for other distributions.

> At present package maintainers seem to be the right people to state if the
> packages are built fine, but if that is not possible then we need to discuss
> this in the upcoming maintainers meeting and take an action.

Building is one thing that is relatively simple. But that does not prove
that the packages are actually functional, or that the required
dependencies (might have changed) are available in the repositories.

It is possible to automate test runs when the builds land in the testing
repository. If we can decide on what tests should run, and pass, and who
will maintain them, that would be a big help.


More information about the maintainers mailing list