On Tue, Nov 27, 2018 at 12:19 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor
> On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
> > I completely disagree. Our release process and tooling is
> > heroism and tech debt. At some point, that is going to cause
> > significant burnout and then people will just wonder what happened
> > when those people stop doing releases. I think it's better to raise
> > awareness at the project level, and build something that is
> > sustainable rather than predicated on "small group of people killing
> > themselves for the greater good". That starts with individual package
> > CI gating, and goes all the way through integration testing between
> > packages in a gated manner, into how we actually *create* all of that
> > plus the things we deem worth of releasing.
> I think you are misunderstanding me somehow. I'm 100% on-board with
> improving the processes, catching compose problems in an automated and
> early fashion, making developers fix their own problems, and generally
> making releases a less heroic process. And if that requires a
> temporary cadence chance to get the retooling done, then it's worth
> But Brendan's proposal to permanently slow down the cadence seems to
> make the assumption that the current release cycle is a heroic effort
> for the entire project - that we're moving too fast to stay on our
> feet. And I don't think that's the case.
That would be a concern to me as well, assuming we stuck with a
*single* cadence and a *single* platform. With the lifecycle
Objective, aren't we targeting multiple cadences and lifecycles? I
mean, we have this today with Fedora Atomic/CoreOS vs. "regular"
Fedora. Maybe Brendan was thinking singular, but I would very much
like the ability in our tooling a process to have both the faster
moving cadence of today AND a slower moving one. That's another
reason I view a temporary halt as worthwhile. If done correctly, it
enables Fedora to fill more usecases and lifecycles than we could ever
accomplish with a single release.
Josh and Owen both have it basically right IMHO. Speeding up the
compose, increasing automation, and making it easier for people beyond
the core crew to do releases all should allow us to make releases less
of a big deal. I would love to get closer to the ostree release (both
in terms of content, and cycle) for the majority of current users.
That means faster, not slower releases -- and that "release" should be
more like a non-event for most people. Not to mention the benefits of
being able to revert the platform in case of a problem, etc.
But I also agree that a longer cycle can have a place too. The tricky
part is to make sure that doesn't turn into multi-stream pain for the
proverbial "1000 packagers" group. There should be a way to set the
cycle and the overlap to minimize pain. (And I suspect modularity also
helps somewhat here.)
Take an average packager who cares about long-term. They may have to
maintain 5+ streams now if you count EPEL. We want an outcome that is
arguably better, or at least no worse. (No, we really want better.)