On Thu, Nov 29, 2018 at 11:15 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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. Yep, I know :) For a lot of packages, this could be done now. I think to get the full benefits from it across the distro, we'd need to really define that platform layer so maintainers know what they can depend on, etc. > It's just not documented or available as an option for setup when you > file a repo creation request. Right. I think we should start encouraging its use. I kind of dislike using 'master' as the branch because it's ambiguous depending on how you look at it, but it's not wrong. A stream branch just provides a bit more context. josh _______________________________________________ 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
