Dne 24. 03. 20 v 19:55 Aleksandra Fedorova napsal(a): > On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: >> On 24. 03. 20 16:23, Aleksandra Fedorova wrote: >>> I am going to answer generally in this mail, before we dive in into >>> discussing the details. >>> >>> I think your approach to assessment of the Change is not fair. >> Ouch. It's just that reading the proposal raises all of those questions. Sorry >> if that's not fair. > Sorry if that sounded offensive. I didn't really mean it. And I am not > against asking questions, please do. > > I do think that not all questions need to be answered now. Not all an > be answered and not all should. So I was trying to propose splitting > it up into what needs to be decided now, and why. And what can be left > later. > > But going too meta probably was a wrong move by me here. So let's get > back to the actual questions. > >>> It is an infrastructure change, not a code one. Figuring out all of >>> the questions you are asking is exactly what this change is about. And >>> you are requesting that we put the entire solution into the change >>> proposal. This is not going to work this way. And it shouldn't work >>> this way. >> The way I see it, it, the change proposal currently describes an "idea". >> I would like it to describe how things are planned to work (at least an initial >> plan for that). >> >>> There is a reason why Change Template has Description section and does >>> not have Design or Implementation. Because design and implementation >>> are left for the owners of the change as we will figure out the >>> details on our way to it. >>> >>> The goal of the Change process is to assess the idea, the impact, to >>> check whether there is a disruption this change brings, and to find >>> people who are interested in it. Then we can work on the change >>> together, working through all those questions you have mentioned. >> I wasn't aware that this is the change process goal. Most of the (approved) >> changes in Fedora actually describe what's going to happen. Changes that only >> describe the end goal are often rejected or significantly amended. >> >> "Change proposals should be shared as early as possible, before the change is >> implemented and even in the very early state of the idea, to gather community >> feedback and review." >> >> https://docs.fedoraproject.org/en-US/program_management/changes_policy/ >> >> This exactly happened here and I am glad it did. But in my opinion, outright >> rejecting the feedback is not fair either. >> >>> You are asking good questions and I value your feedback. But yes, the >>> current answer to most of them is "we do not know yet". >>> For example, even though the structure of the buildroot is proposed in >>> the releng ticket, and we would like it to inherit rawhide buildroot >>> at this point, we may want to change it later. >>> >>> So I'd ask you to split the conversation into two parts: >>> >>> 1) what are the expectation, requirements, impact and risk for this Change >>> This is what we do need to add into the Change proposal, as it sets >>> the boundaries in which we should operate. >> The main risk I see is that this will generate a need for mass pushing various >> conditionals all over Fedora. And while some maintainers like those, some don't. >> And I'm afraid this is not fair to them, if we approve this without knowing. > Do you have a suggestion, how to make it clear that there will be no > enforcement? > > We've put it in the proposal that we are going to provide feedback in > terms of test results visible on the bodhi page using Rawhide Gating. > There are no plans to make gating on that test mandatory, as we leave > it to package maintainers to configure gating in general. > > We may also propose pull requests with changes to some packages when > we'd like to suggest a fix for the dependency or adjust compile flags. > >> The change should at least describe what level of involvement is required from >> other contributors. It it is "no involvement needed" and "we will not bother you >> with conditionals" than I see no risk for Fedora (distro) (but I see a huge risk >> for the ELN project, because it will be unable to fix itself). > The answer here is that we _may_ bother you with conditionals, but we > don't know yet how often it may happen. > Do you want us to keep track on usage of %{eln} in spec files? I think > this is doable. I think that the level of involvement of the other maintainers is the same as what we always did for RHEL. Did RHEL maintainers bothered some Fedora maintainers with some conditionals and what not? Probably. I don't see that should be different. The only difference probably is that that won't be one time effort once in every 3 years, but the flow of requests will be continuous, but hopefully smaller. Actually, this brings interesting question. It seems to me, that it would be helpful if RHEL maintainers had blank approval to access the ELN packages. Vít > >>> 2) how it is going to work >>> This goes to design docs and implementation. We will definitely take >>> all comments from the mailing thread into account. As soon as we >>> figure out the place where we track the effort (most likely, Taiga) we >>> will transfer it all there. But we would like to postpone making >>> decisions on those topics. Because things may change while we are >>> working on them. And it should be ok to change them, as soon as we >>> keep the boundaries. >> I don't see a reason to postpone this discussion. It may affect critical design >> decisions. And we have seen in the past that postponing some problems for later >> (e.g. upgrade path or switching streams in Modularity) can lead to a serious >> design issues that are very hard to fix later. > I wasn't proposing to postpone the conversation. I suggested to split > it into two groups. > And for first group to add a question on "why should we know the > answer to it right now? What does it change? Which risk or requirement > it addresses". > >> I think it would be unfair if this Change in fact has a large impact to average >> contributors, but we only realize this once they are impacted (and discontented). >> >> So, forgive me for being unfair, but I'd rather be unfair to a Change proposal, >> than being unfair to our contributors. >> >> I realize some will consider this "stop energy", but I'm not trying to stop or >> fight ELN (in fact, I am quite exited about it) -- I just ask for more >> information before we can assess it. > So back to buildroot inheritance question as example. We have the > conversation in the releng ticket [1] where the current Koji tag > structure is proposed. With eln buildroot inheriting Fedora Rawhide > buildroot at this point. > If I understand correctly, you are saying this information needs to be > in the Change proposal. > > So if three weeks after we've got the access to the tags we decide to > remove the inheritance as we collect enough ELN packages in its own > buildroot, would you expect us to file another Change Proposal for > another Fedora release to update that? > >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> _______________________________________________ >> 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 > > [1] https://pagure.io/releng/issue/9154 > _______________________________________________ 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
