On Mon, Sep 17, 2018 at 12:20 PM Petr Šabata <contyk@xxxxxxxxxx> 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@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
_______________________________________________
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
Adam Šamalík
---------------------------
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
