[Gluster-devel] [gluster-packaging] Release 4.0: Making it happen! (GlusterD2)

[Kaleb S. KEITHLEY]

On 01/11/2018 11:34 AM, Shyam Ranganathan wrote:
>>>
>>> One thing not covered above is what happens when GD2 fixes a high priority
>>> bug between releases of glusterfs.
>>>
>>> Once option is we wait until the next release of glusterfs to include the
>>> update to GD2.
>>>
>>> Or we can respin (rerelease) the glusterfs packages with the updated GD2.
>>> I.e. glusterfs-4.0.0-1 (containing GD2-1.0.0) -> glusterfs-4.0.0-2
>>> (containing GD2-1.0.1).
>>>
>>> Or we can decide not to make a hard rule and do whatever makes the most
>>> sense at the time. If the fix is urgent, we respin. If the fix is not urgent
>>> it waits for the next Gluster release. (From my perspective though I'd
>>> rather not do respins, I've already got plenty of work doing the regular
>>> releases.)
> 
> I would think we follow what we need to do for the gluster package (and
> its sub-packages) as it stands now. If there is an important enough fix
> (critical/security etc.) that requires a one-off build (ie. not a
> maintenance release or a regular release) we respin the whole thing
> (which is more work).
> 
> I think if it is a GD2 specific fix then just re-spinning that
> sub-package makes more sense and possibly less work.

RPM (and Debian) packaging is an all or nothing proposition. There is no
respinning just the -glusterd2 sub-package.

> I am going to leave the decision of re-spinning the whole thing or just
> the GD2 package to the packaging folks, but state that re-spin rules do
> not change, IOW, if something is critical enough we re-spin as we do today.

I think my real question was what should happen when GD2 discovers/fixes
a severe bug between the regular release dates.

If we take the decision that it needs to be released immediately (with
packages built), do we:

  a) make a whole new glusterfs Release with just the GD2 fix. I.e.
glusterfs-4.0.4-1.rpm  ->  glusterfs-4.0.5-1.rpm. IOW we bump the _V_ in
the NVR? (This implies tagging the glusterfs source with the new tag at
the same location as the previous tag.)

or

  b) "respin" the existing glusterfs release, also with just the GD2
fix. I.e. glusterfs-4.0.4-1.rpm  ->  glusterfs-4.0.4-2.rpm. IOW we bump
the _R_ in the NVR?


Obviously (or is it?) if we find serious bugs in core gluster and GD2
that we want to release we can update both and that would be a new
Version (_V_ in the NVR).

--

Kaleb