On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin <pviktori@xxxxxxxxxx> wrote: > > On 2020-04-02 20:07, Stephen Gallagher wrote: > > On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > >> The change proposal received overly negative feedback by the packager community > >> as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked > >> several times, none of this feedback was reflected in the proposal, only new > >> reasons why this is going to be done the original way were added. It seems that > >> feedback is collected not to find the best technical solution, but rather to > >> find ways to justify a solution that's already decided. > >> > > > > This is needlessly antagonistic, Miro. We've collected the feedback in > > good faith, examined it and then identified shortcomings with it. For > > the sake of clarity in the Change Proposal, I've recorded that > > reasoning there. > > > >> Key questions in the *Detailed Description* remain "out of scope of ELN" or not > >> answered clearly. > > > > If something is not clear, please constructively offer that > > information. I've been doing my best to rephrase and clarify anything > > that has come up. Anything remaining that is "out of scope of ELN" is > > literally just that. ELN's scope is largely "Make Fedora Rawhide more > > useful to downstream so that downstream developers will work there > > instead of internally". > > # What if packages don't build on ELN? > > The question isn't actually answered. Instead, the proposal answers > *how* packages will fail to build in ELN. These are linked topics. ELN is a "build profile" applied to Fedora Rawhide sources. If we take a working Fedora Rawhide content and apply build profile to it, and it breaks, then there two reasons why it may break: 1) the content is different because of the conditional, and this conditional is broken. So we fix it. 2) the build profile is different, then we fix the buildroot and build flags, and pungi config. As we have a working baseline, it means that eventually if we reduce the number of differences we reach the working state. Once we have that working state we can start _adding_ differences again while keeping it in a working state. > # If a package fails to build on ELN, what will happen? > > What will the time limit be? > What exactly happens is a maintainer rejects the pull request? > > # What if there is a new upstream feature RHEL wants in a package, how > will that go in? > > Why is this not in scope? We're bringing RHEL development closer to > Fedora development. Non-Red Hatters don't know how a feature gets into > RHEL, and I don't blame them if they think this will affect their > workflow. Will it? How? It is not a new thing which ELN changes. Red Hat developers have always been working with Fedora on changes. If feature makes sense to Fedora, it is not a matter of the ELN build, it is a matter of bringing it to Fedora Rawhide. ELN is not involved in this process. > # What if I do not want to have %if's in my spec files? > > What happens if ELN SIG cannot find a solution the maintainer is > comfortable with? Again, we use raw Fedora Rawhide packages which work. > # What if I do not want to have %if's in my spec files, but I want to > see how changes show up in RHEL? > > Sorry, but the answer reminds me of Modularity promises that the missing > pieces will be ready in the future. > What will the maintainer actually be expected to do in this case? In Fedora - nothing. ELN is not the answer to all the wishes. And we don't promise that we will ever cover this case in ELN. I don't see any similarities with Modularity here. > >> The proposal should address the impact on all major packaging > >> styles, and while one side of the spectrum (packagers preferring single-spec > >> with conditionals) is covered, there are very few concrete details on the other > >> (packagers interested in simple spec files or completely uninterested in RHEL). > >> The affected packagers are concerned that the current proposal does not in fact > >> benefit Fedora (to an extent that would justify the disruptions), but rather > >> addresses mainly a downstream RHEL concern using Fedora's resources. > > > > This is a great example of the Nirvana Fallacy. Essentially, you are > > arguing that improvements for one group is not acceptable unless it > > improves things for every other group too. > > It doesn't have to *improve* things for the other group, but if not, it > should clearly acknowledge that it makes things worse (or the same), and > say how. Otherwise that group will justifiably feel excluded. > > Say a new package is added to RHEL, which was previously only in Fedora. > The packager doesn't want RHEL conditionals in the spec. The change > doesn't make sense upstream or in Fedora (for example, the crypto > backend needs to be replaced to comply with some regulation). Without > the change, the package (and anything depending on it) cannot be built > in ELN. Yes. It can not be build as ELN component, because ELN is about building Fedora components and this one is not one of them. It is a downstream trouble to deal with such cases. And we can discuss our options there. But it is not Fedora and not ELN. > As I read the proposal, ELN will work with the packager and try to find > a good solution. However, the discussion might be under pressure of RHEL > guidelines. RHEL guidelines have no specific power in Fedora discussions. We want ELN to be part of Fedora, and ruled by Fedora. This is why we submit it as Fedora change on Fedora infrastructure under Fedora policies. It doesn't mean that RHEL engineers can not talk to Fedora package maintainers. It is what open source developers do. And if you are Fedora packager anyone can approach you and suggest something. The ask here is to be open to the conversation, not necessarily to agree to it. > What *actually* happens in this worst case? Will the macros be forced > into the package? > (If yes, please say it explicitly, so we can discuss that! If not, > hooray -- alse say that explicitly!) Nothing happens, really. As I said above, ELN build failures mean we stretched too far from Rawhide. When we hit one of those, we try to resolve it, but the ultimate fallback is always to get back closer to Rawhide configuration. If at some point ELN _becomes_ Fedora Rawhide, then it just stops as a project, because it doesn't make sense anymore. But now it does. Because we have those differences, we have some of those rotten conditionals already, but also build flags and also different comps setup and compose config. It is not the specs alone, which we can change. > Even if the worst case scenatio is very unlikely, it would help thinking > about the not-ideal-but-not-worst cases as well. > > > > Downstream RHEL concerns *are* Fedora concerns. I cannot stress this > > enough: Fedora and Red Hat have a highly symbiotic relationship. The > > more RHEL succeeds, the more support Fedora gets from Red Hat. The > > more Fedora succeeds, the better the resulting RHEL product. It is > > disingenuous to imply that something that "addresses mainly a > > downstream RHEL concern using Fedora's resources" is a net-negative > > for Fedora. > > Yes, that is true! The question is, does the goal justify the means? And > even before that, what exactly are the means (specifically, in terms of > limiting packager autonomy)? There are no such limits proposed. > >> While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a > >> good goal, I believe that doing this in a way that alienates a significant part > >> of our packagers is a disservice to Fedora. The concerned packagers believe that > >> Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might > >> be shifting us to the undesirable mindset that Fedora is only a test bed for > >> RHEL or a RHEL alpha version. > > > > I think you're missing a major point here. The purpose of ELN is for > > *that* to be the RHEL test-bed/Alpha. But we want it to stay as close > > as possible to Fedora Rawhide because that is how we solve two > > problems: 1) lack of consistent involvement by Red Hat engineers in > > Fedora and 2) eliminate the long lag-time between when features land > > in Fedora and when someone evaluates them for RHEL. > > > >> For me this feels like a step back to the [discontinued Fedora > >> Core](https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00091.html), > >> where the packages that were included in RHEL could only be maintained by their > >> RHEL maintainers. Fedora relies on the contributions of non-RHEL developers — > >> and those often have little interest in downstream work. If we alienate the > >> community contributors, it will ultimately lead to a worse RHEL down the road. > > > > I have no idea where you're getting this from, as we've tried to be > > very clear from the start that we want to make the pipeline of Fedora > > -> RHEL much more clear. We're not changing access permissions on > > these repositories. We're going to be opening up some of the "secret > > sauce" so that more of the community can see what we are testing. They > > will have greater insight into the potential usage of their packages. > > > >> For the stated reasons I am *-1 for this change in its current form*. > > > > That is your privilege as a member of FESCo. As I've said, however, I > > think you've misunderstood the situation. > > > >> As said on the mailing list, I'd appreciate if you take the feedback provided by > >> the packagers more seriously and adjust the proposal accordingly. > > > > I have read and responded to the feedback as best I know how. Please > > do not confuse "I disagree and here are my reasons" with not listening > > to the feedback. > > > > > > Lastly, I don't know if you reread the latest updates (that I made > > around three hours ago to the Change Proposal), but I *did* > > acknowledge that we are going to incorporate the possibility of > > maintaining separate specs for ELN and Rawhide for any maintainer who > > absolutely wants to do more manual work. The exact mechanism is going > > to at least partly depend on the results of the dist-git forge move, > > so I haven't incorporated that into the proposal. Functionally, it > > will be very similar to maintaining a separate branch, though. > > _______________________________________________ > > 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 -- 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
