Re: Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux