On Tue, Nov 27, 2018 at 12:19 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote: > > On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: [...snip...] > > > I completely disagree. Our release process and tooling is built on > > > 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 > > it. > > Ah, good! > > > 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.) ;-) -- Paul _______________________________________________ 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
