On Thu, Jan 11, 2018 at 1:56 AM, Kaleb S. KEITHLEY <kkeithle@xxxxxxxxxx> wrote: > 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. While true, this tarball isn't enough. The GD2 build scripts lookup versioning from git tags or from a VERSION file (same as glusterfs). Both of these are not present in the tarball github generates. The GD2 release script generates tarballs that have everything required to build a properly versioned GD2. > > - 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. > +1. We will follow glusterfs versioning not just for the packages, but for the source itself. > 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 > > > > > _______________________________________________ > packaging mailing list > packaging@xxxxxxxxxxx > http://lists.gluster.org/mailman/listinfo/packaging > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
