[Gluster-Maintainers] Meeting Minutes (21st Feb 2018)
Amar Tumballi
atumball at redhat.com
Thu Feb 22 17:37:42 UTC 2018
BJ Link
- Bridge: https://bluejeans.com/205933580
- Download : https://bluejeans.com/s/q9gJt
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#Attendance>
Attendance
- [Sorry Note] : Atin (conflicting meeting)
- Kaleb, Nithya, Ravi, RaghuG (logging off in 20 min), Sunny, Amar,
Deepshika, Shyam, Sunil, Aravinda, Xavi, Kaushal
<https://hackmd.io/MYTgzADARgplCGBaA7DArMxAWAZvATIiFhJgCYarBQCMCYIQA===?both#Agenda>
Agenda
-
Gluster 4.0 - release:
- GD2: Packaging
- Fedora dependency handling. 4 done, few more in pipeline
- Tarball on Thursday (2/22) - Should be possible
- AI: [Kaushal] Update status on Monday to keep risks known
- All good with release notes?
- Individual owners to act upon perf section [raghug]
- Need to start on GD2 [kshlm]
- [RaghuG] Sent out the email
- AI: [Shyam] Complete release notes for RC1, minor edits can come
in the last week
- AI: [Kaushal/Aravinda] Need GD2 release notes from the team, By
Friday
- Testing done?
- AI: [Shyam] RC1 based upgrade testing to be done
- Awaiting perfomance testing results
- Glusto has issues running with 4.0, so not happening for this
release!
- [Ravi] Rolling upgrade testing is working
- [Kaleb] built Ganesha server/gfapi: basic stuff worked
-
- Any risky components?
- Tiering? (call this feature/xlator phases, can confuse wng
feature :) )
- Impact of cluster.force-migration on remove-brick operations, is
a possible blocker
- RC1 dates and blockers
- Dates: ASAP to facilitate upgrade testing and packaging with GD2
- Blockers:
- https://review.gluster.org/#/c/19596/ (AFR + !MD5)
- https://review.gluster.org/#/c/19419/ (Build without
gluster-server)
- Niels on PTO, someone should backport.
- Topic on CentOS6 Server packages can be taken offline
- not offline, remember community; to the mailing list
perhap? --kaleb
- GD2 package in Fedora and other distros
-
Releases in future - A proposal:
- Keep the time of the release predictable
- No tieing of feature to a release
- No more STM (ie, better to do the tiering in code than STM release)?
- Every release is supported for 1 year (with backports for fixes etc)
- Make release numbers move out from x.y.z to yy.mm.dd format ? (Or
any other format too is fine)
- Have 3 releases a year, 4 months apart
— [Atin] I’d like to understand what’s the drawback with the current
model which makes us to think on this direction?
- [Shyam] Intention is not to break Backward compatibility
- [Aravinda] Does it increase branches to backport to?
- Remains as 3 (N, N-1, N-2)
- [Ravi] So does this mean update releases do not happen?
- No, update releases are still monthly, with exception updates
*any-day* for critical fixes!
- I would like to see the update releases go to a two month
cadence if we’re going to keep maintaining three releases.
Packaging!
(usual exception for critical fixes) --kaleb
- [Sunil] How do we address major changes in a release to the
community (for example things like GD2)
- Release notes, is the manner of updating content in a release
- *final* Milestone in github issue is another manner of finding
out what went where
- If issue is known, looking at it gives the release version as
well
- Or use search terms to filter the issues
- and, this remains the same as it is now!
- Major changes need to be announced early and time to deprecate
older way to do things should also be announced
- [Aravinda] Date based versions can cause confusions
- [Shyam] I am in favor of incremental release numbers like
Fedora, instead of date/time.
- AI: [Shyam] Announce changes to maintainers (today) -> By next
Tuesday seek feedback from Users -> 2 weeks hence announce and change the
web page to reflect new scheme (and other work in this regard)
--
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180222/52036c8f/attachment-0001.html>
More information about the maintainers
mailing list