<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace">comments inline<br>
<br>
On 01/10/2018 02:08 PM, Shyam Ranganathan wrote:<br>
</font></div>
<blockquote type="cite"
cite="mid:c3224d91-932c-21b7-d724-d85d6b98bf38@redhat.com">
<pre wrap=""><font face="Courier New, Courier, monospace">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</font></pre>
</blockquote>
<tt>This is a no-op. In github creating a tag or a release
automatically creates the tar source file.</tt><br>
<font face="Courier New, Courier, monospace">
</font>
<blockquote type="cite"
cite="mid:c3224d91-932c-21b7-d724-d85d6b98bf38@redhat.com">
<pre wrap=""><font face="Courier New, Courier, monospace">
- 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 <font color="#cc0000">sub-</font>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)</font></pre>
</blockquote>
<tt>IMO it's clearer if the -glusterd2 sub-package has the same
version as the rest of the glusterfs-* packages.</tt><tt><br>
</tt><tt><br>
</tt><tt>The -glusterd2 sub-package's Summary and/or its
%description can be used to identify the version of GD2.</tt><tt><br>
</tt><tt><br>
</tt><tt>Emphasis on IMO. It is possible for the -glusterd
sub-package to have a version that's different than the parent
package(s).</tt>
<blockquote type="cite"
cite="mid:c3224d91-932c-21b7-d724-d85d6b98bf38@redhat.com">
<pre class="moz-signature" cols="72"><font face="Courier New, Courier, monospace"> - 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)</font>
</pre>
</blockquote>
<tt>One thing not covered above is what happens when GD2 fixes a
high priority bug between releases of glusterfs.</tt><tt><br>
</tt><tt><br>
</tt><tt>Once option is we wait until the next release of glusterfs
to include the update to GD2.</tt><tt><br>
</tt><tt><br>
</tt><tt>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).</tt><tt><br>
</tt><tt><br>
</tt><tt>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.)<br>
<br>
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.<br>
<br>
--<br>
<br>
Kaleb<br>
<br>
<br>
<br>
</tt>
</body>
</html>