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

[Sankarshan Mukhopadhyay]

On Mon, Jul 3, 2017 at 1:33 PM, Niels de Vos <ndevos at redhat.com> wrote:
> On Mon, Jul 03, 2017 at 09:09:38AM +0530, Sankarshan Mukhopadhyay wrote:
>> On Wed, Jun 28, 2017 at 7:36 PM, Niels de Vos <ndevos at redhat.com> wrote:
>> > On Wed, Jun 28, 2017 at 09:55:15AM -0400, Shyam wrote:
>> >> On 06/28/2017 09:02 AM, Niels de Vos wrote:
>> >> > On Tue, Jun 27, 2017 at 03:25:56PM +0000, Gluster Build System wrote:
>> >> > >
>> >> > >
>> >> > > SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.11.1.tar.gz
>> >> >
>> >> > Packages have been built for the CentOS Storage SIG and are available
>> >> > for testing. There has not been a single confirmation that 3.11.0 is
>> >> > working, so there is still no 3.11 pushed to the CentOS mirrors.
>> >>
>> >> I am thinking who does this confirmation? We have package owners, and then
>> >> package testing, but this split role does not have any owners.
>> >>
>> >> Thoughts or what are the expectations?
>> >
>> > Anyone can send a confirmation that this works. I normally only do a
>> > simple "install, create a volume and access" it. Sometimes users send me
>> > their test results, and that is fine for me too.
>>
>> I fear that an open-ended "anyone can" usually indicates that nobody
>> does. If the requirement that install-create_volume-access is
>> mandatory for making it available on CentOS Storage SIG, what are the
>> challenges in making it as part of the application build workflow? Do
>> we have a similar requirement for non-RPM package sets?
>
> It is not only testing the actual build, it is also about testing the
> functionality of the repository. If there are new/updated dependencies
> needed, installation of the RPMs might fail with the update. The tests
> can easily be automated, and there were some volunteers to look at that.
>

It would probably be worthwhile to utilize the process adopted by the
individuals working on the infrastructure ie. existing Gluster CI to
check if these tests can be automated and included as a pre-flight
check on release announcements.

> A few more details can be found here:
>   https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/CI
>
> Installation and upgrade testing is something that we still need to do.
>

Installation and upgrade testing seem like things which can be
automated - perhaps using the Glusto framework. I am not sure - would
be worth validating this assumption with the developers of the
framework.

> Note that Fedora has Bodhi and AutoQA that gates the builds for
> releasing. This does not exist on CentOS, so we rely on tests in
> their CI.
>
>> Also, instead of private conversations around results of the tests as
>> above, perhaps these should be redirected to this (or, any other
>> appropriate) list.
>
> We dont have a "testers" list, and until now we've always used the
> packaging and maintaiers lists (both not private?) to inform about the
> status of the packages before they are released. This helps with
> coordinating the announcements that go out a few days later. Where would
> you suggest to have these pre-announcement conversations instead?

Perhaps this is the time to consider a list for test results. It would
be nice to have results of test runs sent to this list as default cc:
for archiving and easy reference. After all - the release announcement
across mediums (ie. source, .deb and .rpm) seems to be dependent on
good builds existing across them.


-- 
sankarshan mukhopadhyay
<https://about.me/sankarshan.mukhopadhyay>