4:52 a.m.
Hello,
While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
I don't believe such conditions have any value and I think we can
remove them right away.
I think the removal shouldn't affect neither Fedora nor derived
operating systems.
If removed, they will be preserved in the git history anyway, for
anyone seeking historical code.
In some cases the conditionals hold patches that could be removed with them:
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
--
Do you agree it would be safe to remove such conditionals and the code
they hold ?
Do you agree that removing obsolete code such as this brings value to
the package codebase ?
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
6:04 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, 19 Jan 2023 at 10:52, Michal Schorm <mschorm(a)redhat.com> wrote:
Hello,
While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
I don't believe such conditions have any value and I think we can
remove them right away.
I think the removal shouldn't affect neither Fedora nor derived
operating systems.
If removed, they will be preserved in the git history anyway, for
anyone seeking historical code.
In some cases the conditionals hold patches that could be removed with them:
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
--
Do you agree it would be safe to remove such conditionals and the code
they hold ?
For the packages I (co)maintain, I see no value in keeping it. Maybe
somebody has a reason for keeping it in their specs, but I can't see
any value in it.
Do you agree that removing obsolete code such as this brings value
to
the package codebase ?
Yes, it makes it easier for others to open the spec file and quickly
understand what it's doing.
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
I don't think that's worth the effort/noise.
8:36 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
Michal Schorm <mschorm(a)redhat.com> writes:
While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.
Do you agree it would be safe to remove such conditionals and the code
they hold ?
Yes, at maintainer discretion.
Do you agree that removing obsolete code such as this brings value
to
the package codebase ?
No - it's annoying code churn that usually serves no purpose. If
maintainers want them gone, generally they'll remove them.
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
Please don't.
Be well,
--Robbie
8:54 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
> Would you see a value in e.g. some kind of a robot reminding
> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> check)
Please don't.
Would you mind expanding your answer a bit, please?
I'd like to learn why people would (not) like such a check or reminder.
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
>
> Michal Schorm <mschorm(a)redhat.com> writes:
>
> > While playing around with Sourcegraph, which indexed all Fedora
> > package repositories, I was able to craft a query listing all '%if'
> > conditionals referencing Fedora releases that reached EOL.
> >
> > Do you agree it would be safe to remove such conditionals and the code
> > they hold ?
>
> Yes, at maintainer discretion.
>
> > Do you agree that removing obsolete code such as this brings value to
> > the package codebase ?
>
> No - it's annoying code churn that usually serves no purpose. If
> maintainers want them gone, generally they'll remove them.
>
> Would you see a value in e.g. some kind of a robot reminding
> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> check)
Please don't.
>
> Be well,
> --Robbie
9 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 8:55 AM Michal Schorm <mschorm(a)redhat.com> wrote:
On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood
<rharwood(a)redhat.com>
wrote:
> > Would you see a value in e.g. some kind of a robot reminding
> > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> > check)
>
> Please don't.
Would you mind expanding your answer a bit, please?
I'd like to learn why people would (not) like such a check or reminder.
I agree. I usually keep them around for a couple of releases especially
when it has to do with preserving an upgrade path (support f<xx>-2) or for
more recent EOL'd releases if someone wants to manually keep a package
going for a while.
But I see no purpose in keeping around conditionals for anything past 4
releases ago and I see them sometimes when rebuilding packages. I recently
saw one for Fedora 24...
Thanks,
Richard
10:14 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
Michal Schorm <mschorm(a)redhat.com> writes:
On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood
<rharwood(a)redhat.com> wrote:
>> Would you see a value in e.g. some kind of a robot reminding
>> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
>> check)
>
> Please don't.
Would you mind expanding your answer a bit, please?
I'd like to learn why people would (not) like such a check or reminder.
First, there's no benefit to removal. Nothing is harmed by having
something that always evaluates like `#if 0` unless it seriously impacts
readability. Spec file "hygiene" is not inherently good (or inherently
bad) beyond that.
A check or reminder is another nag notification. We don't need more of
those, especially for low-priority items.
And to head something off: it's not better when someone provenpackagers
the change in. Then there's an unnecessary revbump, and the
maintainers's checkouts desync from the main repo (merge
conflicts/rebase).
Be well,
--Robbie
10:37 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping
them ?
I personally very much prefer to keep stale conditionals out of the spec files I work on,
but I also concur that it is reasonable to want to leave this to maintainer discretion.
On Thu, Jan 19, 2023, at 11:14 AM, Robbie Harwood wrote:
> Michal Schorm <mschorm(a)redhat.com> writes:
>
>> On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood <rharwood(a)redhat.com>
wrote:
>>>> Would you see a value in e.g. some kind of a robot reminding
>>>> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
>>>> check)
>>>
>>> Please don't.
>>
>> Would you mind expanding your answer a bit, please?
>> I'd like to learn why people would (not) like such a check or reminder.
>
> First, there's no benefit to removal. Nothing is harmed by having
> something that always evaluates like `#if 0` unless it seriously impacts
> readability. Spec file "hygiene" is not inherently good (or inherently
> bad) beyond that.
>
> A check or reminder is another nag notification. We don't need more of
> those, especially for low-priority items.
>
> And to head something off: it's not better when someone provenpackagers
> the change in. Then there's an unnecessary revbump, and the
> maintainers's checkouts desync from the main repo (merge
> conflicts/rebase).
>
> Be well,
> --Robbie
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> Attachments:
> * signature.asc
10:33 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
Michal Schorm wrote:
I'd like to learn why people would (not) like such a check or
reminder.
The maintainer sees the conditional every time they update the spec.
They can remove it whenever it's convenient to them. There's no need to
pester people about such non-urgent maintenance. It's not like
something will break if the conditional isn't removed in time.
Björn Persson
9:04 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 11:52:04AM +0100, Michal Schorm wrote:
While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
I don't believe such conditions have any value and I think we can
remove them right away.
I think the removal shouldn't affect neither Fedora nor derived
operating systems.
If removed, they will be preserved in the git history anyway, for
anyone seeking historical code.
In some cases the conditionals hold patches that could be removed with them:
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
--
Do you agree it would be safe to remove such conditionals and the code
they hold ?
Only if they're purely for Fedora. In many examples you also see a rhel
conditional and that could be used for EPEL. A good number of packagers
like to use the same spec since it reduces maintenance burden on
updates. So in that case the mentioned RHEL/EPEL version should also be
EOL.
Do you agree that removing obsolete code such as this brings value to
the package codebase ?
Yes, RFC 2119 SHOULD sense.
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
I'm not sure this is great. For example, it may introduce revbumps,
which can cause a package rebuild but in the resulting RPM these should
make no difference (otherwise they wouldn't be safe).
To me the right time is to on version bump of a package where you're
already making changes anyway.
9:13 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>Do you agree it would be safe to remove such conditionals and the
code
>they hold ?
Only if they're purely for Fedora. In many examples you also see a rhel
conditional and that could be used for EPEL. A good number of packagers
like to use the same spec since it reduces maintenance burden on
updates. So in that case the mentioned RHEL/EPEL version should also be
EOL.
I agree.
I'd just add that the same may apply to the %{rhel} macros too - Is
there any need to check for *EOLed* RHEL releases?
I'm not sure this is great. For example, it may introduce
revbumps,
which can cause a package rebuild but in the resulting RPM these should
make no difference (otherwise they wouldn't be safe).
To me the right time is to on version bump of a package where you're
already making changes anyway.
I don't see a need to make a bump and build for every change, only for
changes that are expected to be built.
There are mass rebuilds anyway, so it will be bumped and built eventually.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>
> On Thu, Jan 19, 2023 at 11:52:04AM +0100, Michal Schorm wrote:
> >While playing around with Sourcegraph, which indexed all Fedora
> >package repositories, I was able to craft a query listing all '%if'
> >conditionals referencing Fedora releases that reached EOL.
> >
>
>https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group
> >
> >I don't believe such conditions have any value and I think we can
> >remove them right away.
> >I think the removal shouldn't affect neither Fedora nor derived
> >operating systems.
> >
> >If removed, they will be preserved in the git history anyway, for
> >anyone seeking historical code.
> >
> >In some cases the conditionals hold patches that could be removed with them:
> >
>
>https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group
> >
> >--
> >
>Do you agree it would be safe to remove such conditionals and the
code
>they hold ?
Only if they're purely for Fedora. In many examples you also see a rhel
conditional and that could be used for EPEL. A good number of packagers
like to use the same spec since it reduces maintenance burden on
updates. So in that case the mentioned RHEL/EPEL version should also be
EOL.
>
> >Do you agree that removing obsolete code such as this brings value to
> >the package codebase ?
>
> Yes, RFC 2119 SHOULD sense.
>
> >Would you see a value in e.g. some kind of a robot reminding
> >maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> >check)
>
I'm not sure this is great. For example, it may introduce
revbumps,
which can cause a package rebuild but in the resulting RPM these should
make no difference (otherwise they wouldn't be safe).
To me the right time is to on version bump of a package where you're
already making changes anyway.
>
_______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
9:56 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 04:13:02PM +0100, Michal Schorm wrote:
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
> >Do you agree it would be safe to remove such conditionals and the code
> >they hold ?
>
> Only if they're purely for Fedora. In many examples you also see a rhel
> conditional and that could be used for EPEL. A good number of packagers
> like to use the same spec since it reduces maintenance burden on
> updates. So in that case the mentioned RHEL/EPEL version should also be
> EOL.
I agree.
I'd just add that the same may apply to the %{rhel} macros too - Is
there any need to check for *EOLed* RHEL releases?
That's what I also suggested.
In Fedora we can reasonably say we mostly care about EPEL and if that
goes EOL then it's actually removed from the mirrors.
In theory people could keep the spec compatible so users can manually
rebuild for older release, even if Fedora infrastructure doesn't. Hence
why I suggested SHOULD rather than MUST.
> I'm not sure this is great. For example, it may introduce
revbumps,
> which can cause a package rebuild but in the resulting RPM these should
> make no difference (otherwise they wouldn't be safe).
>
> To me the right time is to on version bump of a package where you're
> already making changes anyway.
I don't see a need to make a bump and build for every change, only for
changes that are expected to be built.
There are mass rebuilds anyway, so it will be bumped and built eventually.
I'm used that for each release there is also a build. My assumption was
that rpmautospec would create a release, but if it's skipped then my
objection would be gone.
To be clear, I'd actually like to see robots sending in pull requests.
Many version bumps are actually trivial and the-new-hotness could send a
pull request. In a similar way I can see some sort of nanny cleaning up
specs in an automated fashion doing the same. For example, conversion to
SPDX license tags feels like a good candidate (if there's no ambiguity).
If this is automated then it should be easy to opt-out on a repository
basis.
On Debian there is lintian-brush[1] which has a similar objective.
[1]: https://salsa.debian.org/jelmer/lintian-brush
10:46 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
Dne 19. 01. 23 v 16:13 Michal Schorm napsal(a):
I'd just add that the same may apply to the %{rhel} macros too -
Is
there any need to check for*EOLed* RHEL releases?
Sometimes yes. I have seen people still using RHEL 5 and building packages for RHEL 5.
It is not needed to be present in Fedora's dist-git but you usually do not know what
is the maintainer workflow. You may
complicate his life over the purity of Fedora's dist-git.
You can submit few PR and you will see how maintainers will react. And the reactions will
vary.
Miroslav
11:15 a.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On Thu, Jan 19, 2023 at 10:52 AM Michal Schorm <mschorm(a)redhat.com> wrote:
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
"Reminding" is another term for nagging. Fedora should
not be a nag when there may be reasons for the choices
(for example, while one can claim that one should not be
running obsolete system versions, sometimes there are
"reasons", and that system may even be being supported
through an extended support contract). Packager
workflow can be complicated, and we need to respect
that the many volunteers that contribute to Fedora may
have needs outside of the pure Fedora ecosystem.
Adding such a check to rpmlint when a packager does
their update checks, on the other hand, might be a
reasonable approach, as packagers can decide whether
to remove the code fragments, to override that check in
the rpmlint configuration, or just ignore the suggestion,
as they see fit.
As for my personal practice, I tend to remove such old
code when I decide to review the entire spec file (i.e.
review/modernize it for current packaging guidelines
typically with a major new version of the software, or
I have just adopted an orphaned package that I need),
or the spaghetti if/elses become confusing even to myself,
and it needs cleaning, or when I am trying to avoid
doing something else (sometimes it seems like cleanup
should be quick and easy (sometimes it is neither)
which I think I can actually accomplish right now).
I rarely go looking for new things to add to my
infinitely long TODO list just because I could add it.
1:12 p.m.
New subject: SPECfiles - conditionals with EOLed Fedora releases - any value
in keeping them ?
On 1/19/23 04:52, Michal Schorm wrote:
Hello,
While playing around with Sourcegraph, which indexed all Fedora
package repositories, I was able to craft a query listing all '%if'
conditionals referencing Fedora releases that reached EOL.
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
Similarly as F36/32-bit arm reaches EOL,
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
Which finds spec's with arm[567] conditionals, and reports there are 230
of them.
It might be a bit early to nag about them but I would assume most of
them will start dropping off RSN.
I don't believe such conditions have any value and I think we can
remove them right away.
I think the removal shouldn't affect neither Fedora nor derived
operating systems.
If removed, they will be preserved in the git history anyway, for
anyone seeking historical code.
In some cases the conditionals hold patches that could be removed with them:
https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproj...
--
Do you agree it would be safe to remove such conditionals and the code
they hold ?
Do you agree that removing obsolete code such as this brings value to
the package codebase ?
Would you see a value in e.g. some kind of a robot reminding
maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
check)
Michal
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
439
days inactive
467
days old
13 comments
10 participants
participants (10)
-
Ben Beasley -
Björn Persson -
Ewoud Kohl van Wijngaarden -
Gary Buhrmaster -
Jeremy Linton -
Jonathan Wakely -
Michal Schorm -
Miroslav Suchý -
Richard Shaw -
Robbie Harwood