On Wed, Mar 25, 2020 at 3:23 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.
>
> 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.
(snip)
> 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.
I don't even think this needs to be hard.
1. For packages where no modifications are necessary, just merge
master into eln whenever master changes
2. For packages where modifications are necessary, either
- push changes into master, when those changes are acceptable
(particularly small changes), and proceed with case 1.
- keep "bigger" changes unacceptable for master/rawhide in eln and
rebase those on rawhide whenever master changes
Given that the number of packages that need such "big" modifications
are expected to be small, this approach should scale very well.
> >>> 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
_______________________________________________
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
