On 25. 03. 20 17:33, Aleksandra Fedorova wrote:
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.
Let's agree on that.
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.
This also applies to e.g. "Fedora Workstation". Using "Fedora Workstation" on
your workstation is possible, but you need to learn first what "Fedora
Workstation" is and you need to make an educated choice to use it. (unless
somebody else makes this choice instead and they install it for you, which also
applies to rawhide or 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.
Neither does your grandma need to be notified about most of the other changes in
Fedora just in order to be able to use it.
Never mind. **I see what you mean.** After all those words I understand what you
meant by the statement. However when reading just the change proposal, the
statement doesn't make sense to me. And if it so complicated to explain, maybe
it makes sense to stop saying there will be no user deliverables and rephrase
it? Say that users of rawhide or Fedora (pre)releases will not be affected. And
say how can ELN users consume it (for their CI or for their mock).
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 get what you **mean**. However I think that "Fedora Server" and "rawhide" are
not comparable or contradicting terms. You can have Fedora Server while having
rawhide. You cannot say "Fedora Server is a stable edition, unlike rawhide".
I don't want to argue about our terminology anymore. I understand what you are
saying in your emails, but I didn't understand what the change proposal is
saying (and I think neither will all others).
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.
I don't see how.
It also cuts community maintainer from the help of downstream, as
downstream will be developing a fork.
This boils down to terminology (again). What you call a fork is a separate
branch. In my eyes a branch with a bcond switched is no more "fork" than a %if
in one branch. Consider this:
Case A:
there is just master branch. it has:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with tests
%else
%bcond_without tests
%endif
Case B:
there are 2 branches. master has:
%bcond_without tests
eln has:
%bcond_with tests
But their content is otherwise identical. How is Case B more fork-ish than Case A?
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... (snip)
Sure. Let's try to do that **before** we move on. And while we do that, consider
different approaches as well.
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.
At the point I was writing this I assumed we are talking about all packages in
Fedora. I was concerned we could lose the maintainers who would leave because of
"forced" changes.
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.
The concept will work for RHEL quite nicely. What I worry about is how it will
work for Fedora. It mind be already decided that RHEL needs this while we would
still be collecting Fedora feedback. Yet again, I was writing that when I
assumed all packages would be affected.
--
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
