On 11/26/18 8:21 AM, Brian (bex) Exelbierd wrote:
On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
>> Here's the summary from the page, which proposes we pause the release
>> after F30 for these efforts:
> I know it was a big time-off holiday week in the US, but I expected a little
> more interest in this post. Perhaps it seemed like too much text to digest
> along with turkey and stuffing. :) I'm highlighting it with a subject
> reflecting the big, direct impact, and here's some other top-level
> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)
> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * define a base platform -- Red Hat wants to focus resources here
> * better tooling for non-base deliverables
> * better metrics for everything
I am +100 to these changes.
The idea that we can essentially not release for a year to do this
raises the interesting point that perhaps our release cadence is not
as rigid as we think it may be. I don't think we are going to skip
Gnome and other major updates, are we? If not, then this also runs
into the conversation about longer lifecycles and whether we need
If we push as updates things we normally wait for releases for, would
that disrupt our users?
Is there a cutoff of things we would push in updates? For example, we
usually do mass rebuilds of the entire collection of packages when new
gcc/etc are ready, would we do that as a update in a stable release?
We could solve the rolling changes issue by requiring all major changes
to be modular and not enable the new module (ie, gnome 3.32 releases in
f30, in 6 mmonths 3.34 comes out, we enable it as a new module, users
can choose to switch to if they want, or stay on 3.32 if they ignore it
or don't want to right then). That won't help for tool changes tho.