On 06/04/2020 22:53, Stephen Gallagher wrote:
Changes in this version of the proposal[2]:
* Improve our explanation of why we are doing ELN in the first place
I agree that the proposal is now a lot clearer and I certainly see
how it furthers the first goral of seeing how Fedora trunk comes
together asn an EL build, modulo one concern below.
I don't understand how it helps evaluate something like a new
higher CPU baseline - nobody disputes that packages can be built
to a new baseline which is what this would prove. The argument
is about the effect on consumers of such a baseline and about
what proportion of users/machines would be cut off from further
upgrades and this proposal does nothing to help with that.
* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)
As far as conditionals are concerned I think not defining %fedora
is a key mistake that will both lead to extra conditionals being
needed and also lead to ongoing undetected failures to build
packages in ELN with the latest features of the corresponding
Fedora packages.
Essentially packages will build as if they are on the oldest
possible Fedora rather than the newest possible Fedora because
spec files with a condition on %fedora will typically treat it
as zero when it is not defined.
That will mean that most %fedora conditions will need to be
extended with a %rhel condition and that in many cases new
features may silently not be enabled in ELN builds until that
is manually discovered and the condition is amended which seems
to be the exact opposite of what is required if the goal is to
see how "Fedora Future" builds in an EL environment.
To take just one example hundreds of nodejs packages would build
as if they are on Fedora 18 or earlier because they contain this:
%if 0%{?fedora} >= 19
ExclusiveArch: %{nodejs_arches} noarch
%else
ExclusiveArch: %{ix86} x86_64 %{arm} noarch
%endif
Now that is no longer required, and happens to be mostly harmless
because it just means they will hard code the arch list instead of
using the macro, but it's the kind of thing where ELN will wind
up building as if it's an ancient version of Fedora rather than as
if it is rawhide.
* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.
It might be better to give some idea of what sort of time limit is
envisioned - as it stands the proposal would allow PRs to demand a
response within a day, or an hour or any other ludicrously short
time period. Presumably if it's about looking for inactive maintainers
then something akin to the non-responsive maintainer timelines would
be appropriate?
Tom
--
Tom Hughes (tom@xxxxxxxxxx)
http://compton.nu/
_______________________________________________
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
