>>> The reason for not having mass rebuild during F25 development cycle is >>> very tight schedule for F25 and we would like to avoid slips in F25 as >>> much as possible. That is the main motivation here. >> In other words sacrificing quality for marketing reasons - Utterly poor :( >> > > It's not sacrificing quality. Mass rebuilds require a great deal of engineering > coordination. We're requesting that such coordination happens in the F26 > development cycle instead, so we don't end up having another long cycle. > > There is strong engineering value in having two releases per year: release > early, release often. There are many projects that develop through Fedora that > get thrown into disarray when our cycle gets too far out of whack (prominent > examples being GNOME and glibc). So given that we needed to extend the F24 > timeframe early on (and also had a couple slips), FESCo agreed to shorten F25 in > response so that we can still deliver the autumn releases of key projects > (without having to re-consider the updates policy like we did for GNOME > 3.14->3.16 during the "Year Almost Without Fedora"). > > All of the major stakeholders that usually trigger a mass rebuild (GCC, glibc, > etc.) have been notified directly and are on board with this. This announcement > was to ensure that no one was left surprised by this in case we missed telling > anyone directly. Really? The email from Florian on this thread 30 mins prior to this one conflicts with that from a glibc PoV and given they're part of the toolchain team and they didn't know does the rest of the toolchain team agree? Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
