Hi, Fabio, On Fri, Mar 27, 2020 at 4:42 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > 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". We are not ignoring the branching suggestion. We have thought about it, and we have argued about it. And the main reason why we don't want to implement branching is not the cost and scalability of it, but the fact that It solves a different problem. The three cases you mentioned describe the solution how we can create a downstream package from upstream. It is a working mechanism, we know that. I have personally implemented a similar thing for Mirantis OpenStack distribution not that long ago. For this task branching makes sense, as well as versioning with RHEL version numbers. But we are not proposing to start building downstream packages by downstream maintainers on Fedora infrastructure. We want to build a new development tool for _Fedora_. Its purpose is to work on Fedora. Its goals are to track and reduce dependency trees in Fedora to help with Fedora Minimization objective, and to find issues in Fedora packaging which makes it harder to use by downstream, and to bring downstream maintainers to Fedora, so that they can help in _Fedora_ development. ELN is a Fedora feature. It helps downstream, it makes Fedora more valuable for downstream, but it is still a Fedora feature. Thus when in case #3 we have a fallback from Fedora to downstream, it falls back not from Fedora Rawhide to ELN, but it falls from Fedora Rawhide and ELN compilation of it all the way back to the downstream. So yes, in case #3, when downstream can not find a compromise with Fedora packagers, even via ELN option, then downstream does the branching. But this branching is not in the scope of the proposed ELN change. > 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 -- -- 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
