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

[Niels de Vos]

On Thu, Jan 11, 2018 at 12:14:20PM -0500, Kaleb S. KEITHLEY wrote:
> 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).

I think it will be really painful to maintain a .spec that has the
current (already very complex) glusterfs bits, and the new GD2
components. Packaging Golang is quite different from anything written in
C, and will make the mixed language .spec most ugly. (Remember the
difficulties with the gluster-swift/ufo bundling?)

If GD2 evolves at a different rate than glusterfs, it seems better to
package is separately. This will make it possible to update it more
often if needed. Maintaining the packages will also be simpler. Because
GD2 is supposed to be less intimate with the glusterfs internals, there
may come a point where the GD2 version does not need to match the
glusterfs version anymore.

Keeping the same major versions would be good, and that makes it easy to
set the correct Requires: in the .spec files.

Packaging GD2 by itself for Fedora should not be a problem. There are
several package maintainers in the Gluster Community and all can
propose, review and approve new packages. If two packages is the right
technical approach, we should work to make that happen.

Niels