On Thu, Nov 29, 2018 at 10:22 AM Paul Frields <stickster(a)gmail.com> wrote:
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
> >> not project wide and doesn't justify slowing down the whole project
> >> permanently.
> > 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.
I'll echo what Paul says below with a +1, but I wanted to touch on
this point a bit because it implies an assumption that the maintenance
model remains the same even if lifecycle options change. I don't
think that needs to be the case, nor do I think it would even be good.
Of the large number of packages that you maintain, how many of them
are critical to freeze at a specific version for a given Fedora
release? Possibly some, but I would think across the distribution it
would not be a huge number. So if there is no essential need to
freeze them at a specific version, why would you want to maintain the
packages *separately* for each release? That sounds like extra work
for no benefit. If we instead take a maintenance approach that you
maintain package foo and it is built for all releases, then you only
really need to maintain it in a singular instance.
Today that is something that can be accomplished with modularity, but
I would suggest that we look at stream branching as a solution even
for regular packages. So you wouldn't have fc22-fc32 branches under
package foo. You'd have foo/stream-<version> and you could build that
wherever you'd like. Couple that with automated CI testing and I
believe you actually decrease your maintenance burden while increasing
There are many details that would need to be worked out and I don't
want to trivialize them, but I do want to at least get people thinking
about it in the long term. If we are going to improve the way we
build and deliver our operating system, we shouldn't assume we can do
that without changing the way we maintain it either.
> 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
> have available.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: