On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote: > This is a summary of a recent thread [1]. > > Traditional branches (such as "f29") have their EOL (end of life) encoded > in the name. But what about stream branches [2] (such as "2.4" or "latest")? > > Stream branches of RPM packages would always have an EOL associated with > them. The format would be on of the following: > a) A date — mostly tied to an upstream version and its EOL. > b) A specific Fedora release — for release-specific packages. > c) Forever — rolling forward with upstream, latest development versions, > etc. > > Module streams would inherit their EOL from the packages they include — the > earliest EOL would win. This could be optionally overridden on the module > stream level by specifying one of the following: > a) A date. > b) A specific Fedora release. > > There would be a policy that a module can reach its EOL in the middle of a > Fedora release to prevent madness. > > We need a way to specify the EOL value and to manage it over time, because > it might change. For RPM stream branches, there is currently a way to > specify an EOL value when requesting the branch [3] — the actual format > might change based on this discussion. However, I'm not aware of a way to > change the value if necessary nor a process associated with that. Also, > there is currently no way to specify an EOL for modules. > > After we figure this out, we also need to make sure the build system takes > that into account (some recent progress [4]) and that the client tooling > (mostly DNF) presents that to the user. > > So... any comments to the concept? Any ideas about workflows or processes > of managing the EOL values? I went through both threads and thought I'd offer my point of view. From experience I can tell that defining the EOL, be it a module or a package, is rather difficult. Even in the rare case where upstream is clear about their support plans, it doesn't mean we have to follow that. We might want to drop the package earlier, or the opposite -- support it on our own long after it was abandoned upstream. I think both cases are somewhat common. And we rarely, if ever, know this information at the branch creation time. So, a few things. If we need to define these for something, I'd rather only do it for modules rather than packages. Not only to simplify the process for everyone but also because I kinda feel that the module maintainer is responsible for the packages they include. I have a hard time imagining packagers maintaining stream branches "just in case someone wants to consume them". They either maintain the module or only care about the release branches. Also if you have a module with 200 components and you derive your module's EOL from the packages' EOLs, you need to be constantly watching all your components and their "arbitrary" EOL dates or risk your module being dropped. I don't think this is very user friendly. I think the rolling model would be the most commonly chosen option. Basically "supported until I decide to kill it in Rawhide". We could then update existing stable modules with a more specific date, such as the date when that release goes EOL. Maintainers should still be able to choose a date ahead of time if they wish but I'd rather not tie it to Fedora release numbers as that doesn't work very well for EPEL. Finally, I also don't see a point in really killing package stream branches. If someone is consuming these, they are responsible. If not, it doesn't matter that they exist. Not sure how much sense this makes. P > [1] Previous thread: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/ > [2] Now "stream branches", formerly "arbitrary branches": > https://fedoraproject.org/wiki/Changes/ArbitraryBranching > [3] Requesting a stream branch + specifying its EOL: > https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_repositories_and_stream_branches_existing_packages > [4] https://pagure.io/modularity/issue/102 > > -- > > Adam Šamalík > --------------------------- > Software Engineer > Red Hat > _______________________________________________ > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
