On Tue, Sep 11, 2018 at 10:08 PM Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik
<asamalik(a)redhat.com> wrote:
> On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw <hobbes1069(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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