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)
_______________________________________________ maintainers mailing list maintainers@gluster.org http://lists.gluster.org/mailman/listinfo/maintainers