[Gluster-devel] What is the answer to the 3.9.1 release question?

[Niels de Vos]

On Mon, Jan 09, 2017 at 06:20:32AM -0500, Kaleb Keithley wrote:
> 
> 
> ----- Original Message -----
> > From: "Kaleb Keithley" <kkeithle at redhat.com>
> > ----- Original Message -----
> > > From: "Niels de Vos" <ndevos at redhat.com>
> > > 
> > > On Sat, Jan 07, 2017 at 10:00:56AM -0800, Amye Scavarda wrote:
> > > > <top post>
> > > > 
> > > > I realize we're behind on this, but I'd like us to make sure we're all
> > > > aligned on releasing good product. Can we say by EOD Tuesday, we're in
> > > > agreement on what we're testing / what's not being tested?
> > > > 
> > > > I know that there's at least a bug or two that are outstanding for
> > > > 3.9, and Vijay will need to weigh in on this as well.
> > > 
> > > Because 3.9 should get updates every month, isn't it good to get
> > > something out that addresses at least some bugs?
> > 
> > My sentiments exactly.
> > 
> > > There does not seem
> > > to be a 3.9.1 tracker, so I can not find any bugs that are marked as
> > > absolute blockers for the update. A pointer to those bugs would be
> > > welcome.
> > 
> > Shall we just recycle the 3.9.0 tracker?
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1350744
> > 
> 
> Perhaps like we do now with versions in bugzilla, where we have only
> 3.8, 3.9, 3.10 (versus 3.8.[0123456...], 3.9.[0123...], etc.) maybe we
> only need a single tracker for all of 3.9?  And another for 3.10? And
> so on.

Yes, it makes tracking and searching for bugs much easier. I also think
that listing the minor version sets an expectation that there are bugfix
updates for the version that was selected. Some users expect to be able
to stay on 3.7.1 and get updates for with, without moving to the next
3.7.x.

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20170109/d243f882/attachment.sig>