On Thu, Nov 29, 2018 at 10:22 AM Paul Frields <stickster@xxxxxxxxx> wrote: > > 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. 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 your quality. 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. josh > 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 _______________________________________________ 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
