On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý <msuchy@xxxxxxxxxx> 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 > >> 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. 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 possible. 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. -- 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
