On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 25. 03. 20 14:06, Aleksandra Fedorova wrote: > >>> By contributing to Fedora Rawhide sources and consuming them as ELN > >>> repositories for testing purposes. > >> > >> The change proposal literally says "There is no user-facing part in this change. > >> No ELN artifacts are going to be shipped to the end-user." > >> > >> As a contributor, how do I consume the content if I cannot consume the content? > >> As I understand it, the "end-user" and "user-facing" terms must have different > >> meanings in this context, right? What is this meaning? > > > > Looks like terminology issue. For me user is a person who uses > > released Fedora, like Fedora 31 Workstation, on their laptop, or > > Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora > > for Fedora server. > > Basically anyone who needs Fedora to solve their own problems, which > > are not related to development of the distribution. > > > > Fedora Rawhide is not a user-facing branch in Fedora, because it's > > purpose is to develop Fedora, not something else. > > Same with ELN. It is not a Fedora Server edition, there is no reason > > to ever use it on a server. It is a rebuild of Fedora Rawhide, and > > it's purpose is the development of Fedora, and help others to > > contribute to that development. > > > > So it is facing contributors, not users. > > > > Different types of contributors though. > > I consider rawhide users our users and I assume many other do consider them our > users as well. I consider upstream projects who run their CI on Fedora our > users. You are not incorrect that this is a terminology issue, however I think > this is a different mindset issue. Please do consider rawhide users and upstream > projects our users when designing things. You are misinterpreting what I said. And it is a terminology issue. You somehow assume that if we call people users - we care about them, and if we call them contributors, they are _just_ contributors, so we don't. This is not what I have said, and please don't put such a mindset on me. The difference between users and contributors is not how you treat them, but a level of knowledge about Fedora internals which is expected from them. Using rawhide on your workstation is possible, but you need to learn first what rawhide is and you need to make an educated choice to use it. Same with ELN. It does not have impact on Fedora Workstation user experience. My grandma, who is Fedora user since Fedora 8, will not see this change on her laptop and she doesn't need to be informed about it. > For example, there is a point to run an ELN on a server - e.g. to run a buildbot > worker on it for some CI tests. I think this is not the server Neil meant. My point was to highlight that ELN is not a "stable edition" like Fedora Server. ELN is Rawhide, its quality is no better than Rawhide quality, its stability is Rawhide stability, its target audience is Rawhide audience. > > >> I'd rather discuss this here and only come to FPC for approval of new guidelines > >> when ready. The FPC members who are likely to discuss this are already > >> discussing this here. Why spitting the discussion into two places? > > > > Sorry, my understanding of why we need RelEng and FPC tickets was > > completely the opposite. Mailing list discussion about the Change is > > generic, and gets side-tracked to one side or the other and digging > > through it to get the pieces which are relevant to FPC topic is > > harder. While ticket has a fixed topic, discussion associated to it > > and the outcome of that discussion. I don't see how you can prevent > > people from discussing the topic in the ticket and move it to the > > mailing list. > > > > If you see FPC ticket as a "request to vote" only, why do we need it > > then? Can't we just invite FPC representative to vote on a FESCo > > ticket? > > We could, but there are existing workflows based on the committees using their > own ticketing tracker to do the voting. Ok. > > >> This is all nice only as long as you prefer conditionals over branching. For a > >> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec file. > > > > It is not really about personal preferences. These are two different > > approaches with different purposes, different results and different > > requirements. > > There are consequences on choosing one other the other. > > Yes. That's what I've been saying since the beginning. Choosing %ifs over > branches has consequences. Choosing branches over %ifs has consequences. Not > being able to choose has consequences. > > > Branching means forking Fedora Rawhide into something else. Which > > eventually will lead to new downstream tree which will ignore the rest > > of Fedora and just use the fork instead. It can be done, but I think > > it will damage Fedora as a project. > > Not if we do automation that constantly keeps them in sync. Is that hard? Most > likely. But it doesn't put additional burden to the community maintainers. It removes community maintainer from the conversation about what downstream is doing. While we want to give community member a voice in that conversation. It also cuts community maintainer from the help of downstream, as downstream will be developing a fork. > >>> Yes, there is a risk that it won't work. And we have a very clean > >>> contingency plan for it: we shutdown the whole thing. > >>> It will be unfortunate, but it is an option. > >> > >> What is to stop us saying "stop acting like we can stop doing this now and start > >> over at this point" when we realize this is hurting the Fedora community, but we > >> need to ship next RHEL? (Sspeaking from experience. Things like this were said.) > > > > I don't understand your question. Nothing ever stops anyone from > > saying anything. But it is FESCo and Fedora Council who have the > > decision power. > > Correct. I just want to avoid us repeating the same mistakes over and over > again. I am afraid this change has a potential to alienate community > contributors and I would like us to consider the problem before we start doing > it and before RHEL is depending on it and before everybody will just repeat "we > cannot change this, because we have this in RHEL already". > > So can we please not rush this and try to figure things ad hoc, but dedicate > some more time to planning things? Especially I'd appreciate if the "how do we > make this work without %if spaghetti everywhere" aspect is considered. We can not fully implement it in the planning phase. It is not a generic question with generic answer. It needs to be decided on a package level. And decision maybe different for each package and for each case. We can come up with guidelines, for example: 1) Try to find a way to resolve the issue without any conditionals first. There should be a reason why package X needs a dependency Y in Fedora and there should be a reason why it is a required dependency and not a recommended one. So why in that case downstream wants it differently? The first approach is just to talk through it. I can assume cases where downstream adds a dependency, as well as Fedora package removing them. Note that bloated dependency trees is a common problem for all binary distributions, it is not an "EL-thing" and we can work on that together. Nicolas has pointed out to another reason why we would get EL-conditionals: the outdated rpm stack in RHEL. But we don't have this problem with ELN, as we are building Rawhide, and rpm stack is going to be the Rawhide rpm stack as well. 2) Minimize and isolate the conditional, and track the reason. As ELN SIG we need to have a place where we collect known reasons for such conditionals. The overall goal is to reduce this set, not to grow indefinitely. As Stephen said we expect it to be about couple of hundred packages. We will be able to track each one of them. (We have rpminspect to run package diffs for us). 3) In complex cases - bring it to community and FESCo. We don't know what those complex cases might be, one of the goals is to find them. So we keep it as an option to bring individual case to a wider audience. To ask for help and to decide on it. > > But if you look at the change you'll see that it has no blocking > > features whatsoever. We are not changing how Fedora is built and how > > it is released. > > 1) This changes how Fedora is maintained. This is not disruptive. If we stop building ELN compose at certain point we don't lose anything for Fedora Rawhide. > 2) This has a potential of changing how RHEL is bootstrapped, making it > essential and hard to cancel. If the whole concept doesn't work, it won't become essential to RHEL. Although this worries me, it is not the problem with canceling the change, it is a problem with us (as Fedora) not having it. > > So if you have a worry that this change is hard to cancel, please > > explain why you think so. > > See the two sections above this one. > > > > >>>>> == User Experience == > >>>>> > >>>>> There is no user-facing part in this change. No ELN artifacts are > >>>>> going to be shipped to the end-user. > >>>> > >>>> As a packager debugging a problem in ELN, how do I consume it? > >>> > >>> It is described in "How to Test" section. > >> > >> Those sections contradict each other in that case. > > > > As I explained before users and contributors are different. ELN > > packages are not to be used at home. These are developer tools. > > I use developer tools at home. Plenty of Fedora users are developers. Plenty of > Fedora developers are Fedora users. I don't understand your terminology at all. > Saying "we are not going to ship this to users" sounds alienating > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- 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
