On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > 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. > 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
