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

[Kaleb S. KEITHLEY]

comments inline

On 01/10/2018 02:08 PM, Shyam Ranganathan wrote:
> Hi, (GD2 team, packaging team, please read) Here are some things we
> need to settle so that we can ship/release GD2 along with Gluster 4.0
> release (considering this is a separate repository as of now). 1)
> Generating release package (read as RPM for now) to go with Gluster
> 4.0 release Proposal: - GD2 makes github releases, as in [1] - GD2
> Releases (tagging etc.) are made in tandem to Gluster releases - So,
> when an beta1/RC0 is tagged for gluster release, this will receive a
> coordinated release (if required) from the GD2 team - GD2 team will
> receive *at-least* a 24h notice on a tentative Gluster tagging
> date/time, to aid the GD2 team to prepare the required release tarball
> in github
This is a no-op. In github creating a tag or a release automatically
creates the tar source file.
> - Post a gluster tag being created, and the subsequent release job is
> run for gluster 4.0, the packaging team will be notified about which
> GD2 tag to pick up for packaging, with this gluster release - IOW, a
> response to the Jenkins generated packaging job, with the GD2
> version/tag/release to pick up - GD2 will be packaged as a sub-package
> of the glusterfs package, and hence will have appropriate changes to
> the glusterfs spec file (or other variants of packaging as needed), to
> generate one more package (RPM) to post in the respective download
> location - The GD2 sub-package version would be the same as the
> release version that GD2 makes (it will not be the gluster package
> version, at least for now)
IMO it's clearer if the -glusterd2 sub-package has the same version as
the rest of the glusterfs-* packages.

The -glusterd2 sub-package's Summary and/or its %description can be used
to identify the version of GD2.

Emphasis on IMO. It is possible for the -glusterd sub-package to have a
version that's different than the parent package(s).
> - For now, none of the gluster RPMs would be dependent on the GD2 RPM
> in the downloads, so any user wanting to use GD2 would have to install
> the package specifically and then proceed as needed -
> (thought/concern) Jenkins smoke job (or other jobs) that builds RPMs
> will not build GD2 (as the source is not available) and will continue
> as is (which means there is enough spec file magic here that we can
> specify during release packaging to additionally build GD2) 2)
> Generate a quick start or user guide, to aid using GD2 with 4.0
> @Kaushal if this is generated earlier (say with beta builds of 4.0
> itself) we could get help from the community to test drive the same
> and provide feedback to improve the guide for users by the release (as
> discussed in the maintainers meeting)
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.)

The alternative to all of the above is to package GD2 in its own
package. This entails opening a New Package Request and going through
the packaging reviews. All in all it's a lot of work. If GD2 source is
eventually going to be moved into the main glusterfs source though this
probably doesn't make sense.

--

Kaleb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180110/cbc6e82e/attachment.html>