Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>> 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.
>
> I don't understand why the focus on the worst case scenario.
>
>
>>>>>> 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.
>>
> It seems there are missing real life examples of what we sometimes do in
> RHEL, so please see attached patch. This patch is coming from RHEL
> version of the espeak-ng. Now somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here.
>
>
> Vít
>
And here is another example for the curious.
Vít
>From ac428c9444b33a1073229ef25bdd9969dd40063f Mon Sep 17 00:00:00 2001
From: Vít Ondruch <vondruch@xxxxxxxxxx>
Date: Jul 19 2018 11:57:29 +0000
Subject: Process the man page using kramdown and remove the ronn dependency.
---
diff --git a/rubygem-tilt.spec b/rubygem-tilt.spec
index 8e9913c..30afe05 100644
--- a/rubygem-tilt.spec
+++ b/rubygem-tilt.spec
@@ -18,10 +18,6 @@ BuildRequires: rubygem(minitest)
BuildRequires: rubygem(nokogiri)
BuildRequires: rubygem(kramdown)
BuildRequires: rubygem(asciidoctor)
-
-# To generate man pages.
-BuildRequires: /usr/bin/ronn
-
BuildArch: noarch
%description
@@ -58,8 +54,18 @@ cp -a .%{_bindir}/* \
# Generate man pages.
pushd %{buildroot}%{gem_instdir}
- ronn --manual="Tilt Manual" --organization="Tilt %{version}" -r man/*.ronn
-
+ for f in man/*.ronn; do
+ cat ${f} \
+ | sed '/^* /i\ ' \
+ | sed 's/* //' \
+ | sed -r 's/<(file|ruby|pattern|value|name)>/*\1*/g' \
+ | sed 's/<br>/\n/' \
+ | sed "/^=/a{: data-date=\"$(date +'%B %Y')\" data-extra=\"Tilt %{version}\"}" \
+ | kramdown -o man \
+ | sed -r 's/(\.TH.*)/\1 "Tilt Manual"/' \
+ > ${f%.*}
+ done
+
mkdir -p %{buildroot}%{_mandir}/man1
mv man/*.1 %{buildroot}%{_mandir}/man1
popd
@@ -103,6 +109,7 @@ popd
%changelog
* Thu Jul 19 2018 Vít Ondruch <vondruch@xxxxxxxxxx> - 2.0.8-8
- Drop BuildRequires: rubygem(rdiscount).
+- Process the man page using kramdown and remove the ronn dependency.
* Mon Jul 09 2018 Vít Ondruch <vondruch@xxxxxxxxxx> - 2.0.8-7
- Drop BuildRequires: rubygem(erubis).
_______________________________________________
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
