On Wed, Apr 01, 2020 at 05:32:08PM +0200, Vít Ondruch wrote:
Dne 01. 04. 20 v 16:01 David Cantrell napsal(a):
On Wed, Apr 01, 2020 at 10:19:08AM +0200, Vít Ondruch wrote:
So although this update clarifies some part, we have not moved anywhere:
~~~
=== Can we do this in a branch instead of in master? ===
This adds no value to the current approach where Red Hat maintainers
would manually merge their changes into the internal build
infrastructure. There's no way to automate the sync from the `master`
branch to the `eln` branch that wouldn't break and require maintainer
involvement. Attempting to branch only individual packages would
introduce significant complexity in the build process as well, leading
to far more opportunity for bugs. Lastly, even the most diligent of
maintainers can forget to sync every change to a new branch, thus
leaving us in a situation where the `eln` branch has fallen behind and
is no longer providing an accurate view of whether the package is still
building or functioning in that environment.
~~~
I wonder where this comes from. I am participating in this thread,
representing Ruby maintainers in RHEL and Fedora, in other places of the
thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
Fedora representative of Perl. All in all, it represents ~1/2 packages
in Fedora/RHEL. I hope that I can say that these people shares a view
that branch, fork, PR is the way to go.
Yet we are not able to convince you. So I wonder who this proposal
actually represents? Who is the target audience? Who are the Red Hat
maintainers you mentioned in the proposal?
I think the FAQ entry above could be phrased better, but my
understanding is
that we should really want rawhide to be where upstream RHEL work
happens.
Creating another branch for this work effectively creates two rawhides
and I
think ELN would suffer as a result.
Of course what can go into Rawhide should go into Rawhide, but that are
not ELN/RHEL conditionals.
I think this is part of what ELN is trying to address to make all of our lives
easier. For the longest time we've had a separation between Fedora and RHEL
dist-git and that means we double (or more) our work. Conditionals in rawhide
spec files to alter the build is exactly the kind of stuff we should have in a
rawhide spec file. If we don't do it there then we're doing it elsewhere and
the work will lag. Personally, I'd prefer to maintain this stuff in one
place.
Another way I'm thinking about it is the downstream consumption of rawhide.
sgallagh, maybe you could add a graphic depicting this in the proposal. I
view rawhide as what is common for all descendents: Fedora, CentOS, and
RHEL. From rawhide we will branch for Fedora releases but CentOS will also
take it. If there are CentOS specifics that are not common to Fedora, then
CentOS Stream is where that work should go. *but* CentOS Stream should also
be what's common between all of its descendents--CentOS and RHEL. Then going
from CentOS Stream to RHEL will allow for further integration of specifics
that are only unique to RHEL. It should be downstream only rather than
bi-directional. Build conditionals in rawhide mean we can maintain those
things in one location (and build there) before it's ever consumed by CentOS
Stream or RHEL.
Vít
Another thing to consider is that we should want ELN builds happening as
rapidly as rawhide builds. ELN is not something to set up and
maintain as it
were RHEL.
Thanks,
Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):
I sent out the V2 version of the Change on Friday and then promptly
managed to injure myself and be away from email until today. I've read
through the email threads again this morning and I decided that,
rather than try to address them one by one, I'd try again with a V3
that hopefully answers some of the repeated questions and concerns on
that list.
Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].
[1]
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569904&oldid=569809
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
--
David Cantrell <dcantr...@redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
