On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> On 25. 03. 20 12:37, Fabio Valentini wrote:
> >> So let's assume for the sake of the argument, that Python is broken in ELN and
> >> the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their spec
> >> files. Now all 3600+ Python packages will fail to build in ELN because of this
> >> and the feedback provided in bodhi will be moot. What will happen then?
> > What about using an additional "eln" branch in dist-git?
> >
> > - For most packages, the master branch should be able to be merged
> > into eln regularly (or even automatically, triggered by master
> > commits).
> > - For the packages that need "unacceptable in master" adjustments, an
> > automatic rebase on top of new master commits could be attempted, and
> > if that fails, human intervention is necessary anyway.
>
> Yes, that makes sense to me. Especially with automation (bacause without it, the
> branch would simply get stalled, you cannot rebase all Fedora packages manually
> at this scale).
As I mentioned in the previous mail, branching goes against the
purpose of the effort.
What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.
Doing this with branches is going to be much harder. When you update
package with conditionals you do need to care about the effect on
various ifs, but you do need to change the package only once at one
place. And then the tree of branches which we create from Fedora
Rawhide will get this change automatically with no effort.
Of course not ifs are equal. It may require some refactoring on the
code side to make the ifs cleaner. I know kernel people did that with
a kernel package to reorganize patches which are applied.
But this is exactly the work we are looking for: the negotiation
between downstream maintainers and Fedora maintainers to make things
work together. We already have branching, it is easier as it allow us
not to talk to each other, but it doesn't solve anything.
And yes, it means that people are going to be _bothered_, and
_pressured_ on figuring out the best way to collaborate. But isn't it
our job?
And again, if you make it easier for downstream to work with Fedora,
you give downstream the reasons to bring their resources. Things like
quality assurance and help with bug triage and bug fixes, things like
cross-project feature development. This is a two-way collaboration
effort.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Aleksandra Fedorova
bookwar
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
