On Wed, 2020-03-25 at 13:09 +0100, Aleksandra Fedorova wrote:
> 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?
No, that's not what your proposal implies. Instead, people are going to
be bothered and pressured to accept the _only_ way to collaborate: put
conditionals into their spec.
> 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.
Do you suggest that RH maintainers, who have mostly their hands full
maintaining _their_ packages, are going to start maintaining _more_
packages? I find that highly unlikely.
D.
_______________________________________________
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
