Re: Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Mon, Nov 26, 2018 at 4:23 PM Brian (bex) Exelbierd
<bexelbie(a)redhat.com> wrote:
On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller <mattdm(a)fedoraproject.org> 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.
I like some of the ideas here but I feel we need to have an extremely
well defined set of problems to be solved else we'll delay the
release, achieve very little, and either never release again or not
have anything achieved except a waste of time.