On 3/30/20 12:54 PM, Aleksandra Fedorova wrote:
On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
It is kind of irony, that the ELN branch idea is still rejected.
I've made several attempts to explain this decision. You are ignoring them.
Therefore there will be PRs coming from Stephen's and Alexandra's (or
anybody else in ELN SIG) forks of packages, containing changes needed to
build some packages in ELN, which nobody is going to merge. In the
meantime, the ELN builds will keep failing.
I wonder why there can't be PR's coming from ELN branch. That would
1) Allow the ELN builds to pass.
2) Audit the work to do.
3) Give it some structure and therefore discoverability.
Just to be clear, I don't plan to accept any PR adding any "if rhel" and
similar into package I currently maintain in Fedora, sorry. Being
maintainer in Fedora and RHEL, I could have done it any time and I did
not. In every package I adopted/inherited during the years, I have
removed such conditionals, because they are PITA. While the proposal
helps with the maintenance of such conditionals, it would still harm
freedom of Fedora to innovate. I understand what is the cost and it is
not worth of it.
To be honest, I see a completely different kind of irony here.
For years Fedora packagers have to deal with nonresponsive upstreams.
How often we go to upstream developers, trying to convince them to
remove bundled libraries, adjust the licensing, to add a configuration
option, to split into subcomponents, to stop hardcoding docker in
their build system..
We know this struggle, we talk about it a lot, we discuss how we can
make upstream to listen to us, how we should help each other..
The changes you list benefit upstream (as well as downstream), so of
course it's reasonable to merge them there.
But I don't think anyone of us expects upstreams to merge
downstream-only changes. And that's exactly what you're proposing. So
this argument feels a bit disingenuous to me.
Tomas
And then, when we play the role of the upstream, we completely forget about it.
Now, I understand people's concerns about merging some downstream
specific changes into the upstream sources without proper design or
without agreement. And we highlighted several times that we are not
going to do that.
But the fact that I need to convince Fedora packagers that they should
at least listen to the problem downstream has, and at least try to
think about how it can be addressed, through conditionals or through
refactoring, or through upstream changes.. this surprises me. I
definitely didn't expect the "don't even try to bother me with those
topics" reaction.
Vít
Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):
There has been a lot of (really good!) discussion on the original
proposal thread, but as it has grown too large to follow anymore, I'm
restarting it. I have made numerous changes to the Change Proposal
page to improve the scope of the proposal as well as clarify some of
the questions that have come up repeatedly in the original thread.
Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].
== Summary ==
ELN is a new buildroot and compose process for Fedora that will take
Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
compose. Feedback from this build, compose and integration testing
will be provided to Fedora packagers so that they can see the
potential impact of their changes on RHEL development.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha@xxxxxxxxxxxx
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh@xxxxxxxxxx
[1] List of changes between the original and new versions:
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569655&oldid=569549
_______________________________________________
devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to
devel-announce-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-announce@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
