On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a):
>> In other words, the "technical debt" we are trying to solve here is
>> not project wide and doesn't justify slowing down the whole project
> I completely disagree. Our release process and tooling is built on
> heroism and tech debt.
People working on release and people working on packages maintenance are different group
- they are not disjunct, but it
is not the same group.
For example *I* am a maintainer of lots of packages, but the additional works because of
the fedora release is about one
working day per year - and it is mostly because of fedora-upgrade package. Other packages
do not need so much work. I am
more affected by upstream releases.
Do not forget that annual releases will mean that N-1 release will implicate 24 months
support for packages which will
mean a much more significant impact on us-the maintaners.
Let's not get too focused on an annual release (or any specific
timeframe for longer release). I know this is something that some
people want. I understand that, and it's *possible* to do in a future
state where more people are empowered to make releases happen. But a
longer release is not the primary goal, merely something that's
I'm more interested in a shorter release that implies less added
maintainer effort. We already put time into Rawhide, and I would like
to see that better leveraged in what we push to consumers. Right now
our branch cycle is six months, at which point we have numerous
freezes and other operations that consume a lot of manual time. They
also bottleneck our pace.
I want to increase automation, decrease manual bottlenecks and
freezes, and spread out permissions to assemble and push out "ready"
content. I would like to optimize for a faster release, making any
slower releases possible. Those releases should be based on what the
consumers of that release need, as well as the efforts our maintainers