On Fri, Mar 27, 2020 at 4:12 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. I still think the only way to resolve conflicts (at least in some cases) will be to have the option of a separate eln branch in dist-git. Multiple people other than myself have voiced this opinion in the original thread, but this option is still not mentioned in the Change Proposal at all. Maybe my suggestions were not clear enough, so let me try again. Proposal: Use an (optional) eln branch in dist-git to resolve conflicts. ## Case 1: Improvements are applicable to both fedora and RHEL-next In this case, there should be no conflict and no need for %if spaghetti, changes can go into the master branch directly, without conditionals. The eln branch can either merge from master directly, or be a symbolic link to it (TIL about symbolic refs in git). ## Case 2: Changes can easily be expressed with %if conditionals and are clear to understand and easy to maintain In this case, I think some maintainers might accept such changes in rawhide. Same result as for Case 1. If maintainers do not accept those changes, "goto Case 3". ## Case 3: Changes are big and/or not accepted for master by the fedora maintainer In this case, conditional-based solutions are probably ugly and need special care. I assume any regular rawhide change will break ELN builds, since the conditionals will not be in effect for rawhide builds, and fedora packages will probably not care. Here, the eln branch can contain "downstream" changes, and it can be rebased on top of master/rawhide automatically. If an automatic rebase does not work, the ELN maintainer would have had to adapt the .spec file manually anyway, so it does not matter to them if this happens in the eln branch, or in the master branch (additionally, this kind of maintenance should be easier, since neither the fedora, nor the ELN maintainer has to deal with %if spaghetti!). Additionally, since you're only going to build a reduced package set for ELN, and I think you mentioned that you expect the number of packages which will require "bigger" changes to be small, this should scale very well. It would also give maintainers an "upgrade path" in the case the eln and master branches are initially the same, but would need to diverge later. I hope this makes it clearer why I think using branches as a conflict resolution tool - like for any other "release stream" - is more general, and superior to "[we] will discuss alternative approaches on an individual basis". Please at least seriously consider this suggestion - up until now, you only dismissed using branches with "this will not work / scale". Fabio > 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 > -----BEGIN PGP SIGNATURE----- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q > 6DnLPiZt > =42JI > -----END PGP SIGNATURE----- > _______________________________________________ > 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
