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.
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'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.
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.
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.
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.
2) This has a potential of changing how RHEL is bootstrapped, making it
essential and hard to cancel.
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
_______________________________________________
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
