On 11/26/18 8:21 AM, Brian (bex) Exelbierd wrote: > On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: >> >> 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 >> proposals: >> >> * 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 > releases, imho. Indeed. 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. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
