On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Nov 29, 2018 at 10:22 AM Paul Frields stickster@gmail.com wrote:
On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý msuchy@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 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.
We can change this _today_, actually. fedpkg supports an in-repo config file to specify distro targets to push whenever running `fedpkg build`. So you could do a repo with only a master branch and have it push to all distro targets enabled for the repo at once. This is probably a useful optimization for the overwhelming majority of packages held by packagers.
It's just not documented or available as an option for setup when you file a repo creation request.