On Tue, Sep 11, 2018 at 10:08 PM Richard Shaw <hobbes1...@gmail.com> wrote:
> On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik <asama...@redhat.com> wrote: > >> On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw <hobbes1...@gmail.com> 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@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
