On Tue, Sep 11, 2018 at 10:08 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik <asamalik@xxxxxxxxxx> wrote:On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:As a packager, what is your experience with lifecycles of your packages? Do you get a specific EOL date from the upstream? If not, at what circumstances you would retire an old version of a package? How do you decide when to go for a new version if there is any?I don't have too many upstreams that "sunset" a particular version (usually the Fedora release schedule stays ahead of that) but I know others do. I really have just two main workflows:1. End user program which I keep up to date on all non-EOL Fedora releases.2. Libraries which I try to not make API/ABI breaking changes within a release (sometimes changes in dependencies make this difficult).I see stream branches helping with both...In the case of #1, I would have "one branch to rule them all" instead of having a branch per release. (also helps solve the first issue below)
Yes, that was one of the main reasons. Glad you like it.
In the case of #2, I would have a branch per major or minor release (whatever upstream maintains as non-ABI breaking). For instance, OpenImageIO I have both 1.7.x and 1.8.x releases being maintained. I would just have a branch for each. When F27 goes EOL that will be the last Fedora release on 1.7.x so that stream branch would be able to go EOL but 1.9/2.0 is going to be released soon so I would request a new stream branch for it and only build/rebuild dependencies for Rawhide (unless there was a compelling reason to include it in F29).
There is another concept in Modularity we can use here: defaults. You could have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora releases, but have different default for each. So in your case, F27 could have 1.7 as a default and F28+ could have 1.8 as a default.
Independently of this, you could also retire 1.7 with the end of F27 if there was no need to have it in the future releases.
This would take care of most of the complains about people using "git merge master" across release branches (even though that's the workflow documented in the wiki). I know I CAN use git cherry-pick but I've never used it before and again, I'm not a program. Almost everything I've learned about git is through Fedora package maintenance and some small pull requests for minor build fixes with packages I maintain.The hard part for me is maintaining EL 6/7 branches. I know there are a lot of complaints about using %if conditionals in specs to have one spec file for all Fedora and EPEL releases and I agree when it gets to be too much it makes the spec very unreadable especially by others (proven packagers) that may have to step in and make changes. If stream branches could somehow make this easier that would be great.
Right now the idea is to have one branch with a particular version for all releases, therefore some %if conditionals in specs could be necessary. On the other hand, there would be just a single spec that builds everywhere. However, we might think about having more branches for one version, if there is a need to have a different source for let's say Fedora and EPEL.
_______________________________________________I'm okay with having to create some sort of "control" file to say what Fedora releases should be built from a stream branch but there needs to be an easy template either cut and pasted from the wiki or that one of the packaging tools can produce.We'll do our best. :-)Thanks!Richard
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
