On Mon, Sep 17, 2018 at 12:20 PM Petr Šabata <con...@redhat.com> wrote:
> 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. > That's exactly what I was worrying about. > > 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. > This is an interesting idea and I think I like it. I'll try to rephrase just to confirm I got it right: You are proposing, that instead of having package stream branch owners, we would only have module owners, who would maintain the packages they build. That probably means: 1. Only modules have an EOL. 2. You maintain what you build — if multiple modules build a single package, they would collaborate on maintaining it. 3. There is no point in having a package stream branch-level EOL — these packages are not getting built outside of modules. And module maintainers should maintain them if they build them. 4. We might not need to retire package stream branches — again, these packages are note getting built outside of modules. And module maintainers should maintain them if they build them. Really interesting idea! Might require a few policy changes. > 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. > That's my favourite, yes, although I can see cases for the other two as well, even though they probably won't be used as often. > > 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. > I tend to agree, even though we would need a few changes in the policies around ownership I've mentioned above. > > Not sure how much sense this makes. > > P > > > [1] Previous thread: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/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@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Adam Šamalík --------------------------- Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
