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)
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).
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.
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
