Re: Should the policy documents better reflect real package maintenance practice?

[Gary Buhrmaster]

On Thu, Nov 24, 2022 at 1:40 PM Miroslav Suchý  wrote:

> I have to make confession. I am breaking this guidelines too. With releasing 
> of new version of Mock and fedora-license-data. The problem for me is that 
> the list of these exception is not available and not maintained. I inherited 
> Mock from Clark and later gave it to Pavel and I am now merely co-maintainer. 
> So I really do not know if Mock has had the exception. And because no one 
> enforce it I even did not apply for the exception for fedora-license-data and 
> I use common sense, becase it does not have sense to have old data in stable 
> branches.

Unfortunately, this discussion runs into a multidimensional
matrix of considerations, and different people may make
different choices at each checkbox.

* Type of update:
   - bugfix (only)
   - feature changing (adding/deleting)
   - API/ABI breaking

   "security" updates may be any/all of those
   depending on the specifics

* Package maintainer type (gross simplification)
   - Developer
  . can backport and write patches if needed
and may even participate with upstream
   - "Casual" or "foreign" packager (bad terms, but..)
  . may not be familiar with the package,
the use cases, or the language.

* Expected class of user of the package:
   - Developer
   - User

 Yes, one can be both while wearing
 different hats sitting in front of the
 same screen at the same time

* Type of package:
   - Tooling (only) which mostly impacts developers
   - Basic Infrastructure (systemd, glibc)
 . "critical path" packages?
   - General purpose use (firefox?)

* Expectation of the consumer:
   - Absolute stability (may be unobtainable)
   - "Best" available (best is overloaded)

* Maturity of the release
   - Current
   - Current - 1

   And the reason I tend to separate these
   is that I tend to expect that current is
   more likely to need fixes soon after the
   rubber meets the road (release), when
   the real QA happens, while current-1
   can be considered more towards stable.
   (i.e. critical fixes may need to be
   backported, but other types of fixes
   can be acquired by upgrading to
   current).


Some of the bullets end up overlapping
in different ways, but if one looks close
enough there are probably examples in
all the various dimensions.


And, of course, selection bias holds in
this discussion, as this list membership,
I would suggest, may not reflect the greater
communities desires.


For the (few) packages I maintain, I try
to only port targeted bugfixes to stable
releases, and new versions go into rawhide
(which eventually percolate to the next
release).  Security fixes can be (have been)
an exception, where an entirely new version
may be necessary everywhere in practice.



And then there is EPEL versions.  Another
bushel of worms.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

On 2022-11-24 13:26, Stephen Smoogen wrote:


It has to do with differing opinions on that and in the first part of 
the sentence. There is

A) Updates should aim to fix bugs, AND not introduce features.
B) Updates should aim to fix bugs, and not introduce features.
...
Whenever I have talked to FESCO members over any large change, they 
have said it was the B form they meant and they were ok with updates 
if it was the way to fix things.



Sure, I think that's a good illustration of one of the ways the policy 
could be more clear.


But in the context of most of the examples I provided, I think the 
policy and practice diverge even when B is the intended meaning.  
Blender was updated from 2.93, which is *still* an actively supported 
LTS branch (until June 2023), to version 3; if there were critical bugs 
to fix, that could have been done with a much less drastic update.  
Emacs' changelog is fairly brief, but I'm not aware of any critical bug 
fixes that necessitated an update from 27 to 28.  Thunderbird seems like 
it's usually maintained upstream for slightly longer than it lives in 
Fedora. Those don't really fall into the category of updates that are 
required, in order to deliver bug fixes, where the upstream developer 
isn't providing them for the branch already in Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Adam Williamson]

On Thu, 2022-11-24 at 14:08 -0800, Kevin Fenzi wrote:
> 
> The policy is also a bit unclear (or just wrong as written) saying
> exceptions need to file for every update or can be just 'you have an
> exception for this package/collection of packages unless something
> changes'. 

The way I read this bit is that the packages listed in the policy have
'permanent' exceptions; if you don't have one of those 'permanent'
exceptions, you must request a one-time exception from FESCo every time
you want to do a bump, and those one-time exceptions don't get written
into the 'permanent' list.

I agree it's not super clear, though. And clearly we aren't 100%
following those rules.

There's another point where we lack clarity, I think. The policy mixes
the words "must" and "should" a lot. But it doesn't make it very clear
if it's really following a strict meaning for those, like the packaging
policy, or if some of the "shoulds" are really intended as "musts"...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Kevin Fenzi]

On Thu, Nov 24, 2022 at 01:42:20PM -0800, Adam Williamson wrote:
> 
> Thinking it over some more - I think Gordon's right that I hadn't
> considered all the language - I think my personal opinion would be that
> the policy should be adjusted to be less opinionated on this idea of
> "introducing features", and concentrate more on "unexpected changes to
> the user experience". There are a lot of cases where introducing
> features is entirely benign, after all. If a CLI tool I use grows a
> useful extra option while still supporting all the ones it had before
> and behaving in the same way when using those, that just does not seem
> like something to be concerned about. I'd happily send such an update
> to stable.
> 
> If the update *removes* some existing argument, or changes the
> behaviour of one, that's much more significant.
> 
> This is really kinda the rule about API/ABI changes, only for
> applications, in a way. Adding new functions to a library doesn't
> change the API, only removing or changing the behaviour of existing
> ones.

I agree. I think this is something we have in the past for gui things
called 'changes in the user experence'. But yeah, we could clarify this
better. 

FWIW I think some cases were grandfathered in when the policy was first
aadopted. firefox and kde for sure. I know I requested a exception for
calibre. 

The policy is also a bit unclear (or just wrong as written) saying
exceptions need to file for every update or can be just 'you have an
exception for this package/collection of packages unless something
changes'. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: spin-kickstarts package

[Kevin Fenzi]

On Wed, Nov 23, 2022 at 09:33:48PM -0500, Neal Gompa wrote:
> 
> Is there a reason we couldn't just automatically update the package
> once we're in freeze so that it has what we're shipping? By the time
> we're down to the wire for final freeze, we're not changing the
> kickstarts that often.

Thats what we used to do, but it has a bunch of process overhead. 

Someone has to file a blocker bug on it, it gets voted on and approved,
then the package update has to be made, submitted, karma and request to
go stable. 

A few times in the past we _have_ made kickstart changes during rc's,
then it means we have to update the package and do all the overhead
again. 

I'm just not sure what utility the package has, wouldn't everyone just
get it from git and make sure they have the latest? 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Adam Williamson]

On Thu, 2022-11-24 at 16:26 -0500, Stephen Smoogen wrote:
> On Thu, 24 Nov 2022 at 13:12, Gordon Messmer 
> wrote:
> 
> > On 2022-11-24 03:13, Michael J Gruber wrote:
> > > I guess there's (at least) two ways to understand "stable":
> > > 
> > > - things don't break
> > > - things don't change
> > 
> > 
> > True, but the policy document is explicit about which meaning is
> > intended, reading, "Updates should aim to fix bugs, and not introduce
> > features, particularly when those features would materially affect the
> > user or developer experience"
> > 
> > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
> > 
> > 
> It has to do with differing opinions on that and in the first part of the
> sentence. There is
> A) Updates should aim to fix bugs, AND not introduce features.
> B) Updates should aim to fix bugs, and not introduce features.
> 
> Reason A with a strong logical AND means that things should be backported
> for any bug fix. In this case, you are probably never going to see any bug
> fixes occur in the distro as most software projects will say that the bug
> is only fixed in the latest version which of course added 9 features. Since
> this is usually a large amount of work for someone who may only have taken
> the package to keep it in for a dependency, you would then just see those
> fixes in rawhide (if at all).
> 
> Reason B with a weak language 'and' means that you shouldn't do updates
> just to introduce new features but in order to fix things. This means that
> if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP,
> etc are either a package set they say is LTS OR in the latest.. you are
> going to see updates occur.
> 
> Whenever I have talked to FESCO members over any large change, they have
> said it was the B form they meant and they were ok with updates if it was
> the way to fix things.

Thinking it over some more - I think Gordon's right that I hadn't
considered all the language - I think my personal opinion would be that
the policy should be adjusted to be less opinionated on this idea of
"introducing features", and concentrate more on "unexpected changes to
the user experience". There are a lot of cases where introducing
features is entirely benign, after all. If a CLI tool I use grows a
useful extra option while still supporting all the ones it had before
and behaving in the same way when using those, that just does not seem
like something to be concerned about. I'd happily send such an update
to stable.

If the update *removes* some existing argument, or changes the
behaviour of one, that's much more significant.

This is really kinda the rule about API/ABI changes, only for
applications, in a way. Adding new functions to a library doesn't
change the API, only removing or changing the behaviour of existing
ones.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Stephen Smoogen]

On Thu, 24 Nov 2022 at 13:12, Gordon Messmer 
wrote:

> On 2022-11-24 03:13, Michael J Gruber wrote:
> > I guess there's (at least) two ways to understand "stable":
> >
> > - things don't break
> > - things don't change
>
>
> True, but the policy document is explicit about which meaning is
> intended, reading, "Updates should aim to fix bugs, and not introduce
> features, particularly when those features would materially affect the
> user or developer experience"
>
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
>
>
It has to do with differing opinions on that and in the first part of the
sentence. There is
A) Updates should aim to fix bugs, AND not introduce features.
B) Updates should aim to fix bugs, and not introduce features.

Reason A with a strong logical AND means that things should be backported
for any bug fix. In this case, you are probably never going to see any bug
fixes occur in the distro as most software projects will say that the bug
is only fixed in the latest version which of course added 9 features. Since
this is usually a large amount of work for someone who may only have taken
the package to keep it in for a dependency, you would then just see those
fixes in rawhide (if at all).

Reason B with a weak language 'and' means that you shouldn't do updates
just to introduce new features but in order to fix things. This means that
if the upstream which in the cases of Firefox, Thunderbird, emacs, GIMP,
etc are either a package set they say is LTS OR in the latest.. you are
going to see updates occur.

Whenever I have talked to FESCO members over any large change, they have
said it was the B form they meant and they were ok with updates if it was
the way to fix things.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Dan Čermák]

Hi Daniel,

On November 23, 2022 5:44:01 PM UTC, "Daniel P. Berrangé"  
wrote:
>On Wed, Nov 23, 2022 at 01:20:24PM +0100, Ralf Corsépius wrote:
>> 
>> 
>> Am 23.11.22 um 12:20 schrieb Miro Hrončok:
>> > Hello.
>> > 
>> > Based on my conversation with Fridolín Pokorný @fpokorny, I've removed
>> > them from their Fedora packages.
>> > 
>> > They left Red Hat and are no longer interested in maintaining Fedora
>> > packages.
>> 
>> I am wondering, why Red Hat/FESCO/... still hasn't found some "formal"
>> successor regulations/proceedures to migitate such cases, provided they have
>> happened many times before, in all the years, Fedora is around?
>
>The mitigation/successor strategy is to have comaintainers for every
>package.
>
>Unfortunately our tools enforce the notion of a "main admin" and
>if that person leaves that role has to be given to another
>comaintainer explicitly.

In my personal packaging experience that wouldn't really help, as all packages 
that I have been involved in, have been or are maintained by a single person, 
irrespective of the number of admins. And once it gets orphaned, none of the 
"ordinary" admins pick it up.

But that's just my experience, yours might (and probably does) differ.

>IMHO we would be better off eliminating the notion of 'main admin'
>entirely and have all co-maintainers be at the equal level, so there
>is no need for a dance to give packages to comaintainers. There
>should only be manual action needed if the last comaintainer quits.
>
>A workaround for the 'main admin' problem is to have a robot account
>as the 'main admin' and all the real people as merely 'admin', so
>the main admin never leaves, but that's a bit tedious to setup.
>
>With regards,
>Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

On 2022-11-24 09:28, Adam Williamson wrote:

The update policy is very keen on discouraging *compatibility-breaking*
updates.



That's true, it does explicitly discourage compatibility breaking 
updates.  But it also says "Updates should aim to fix bugs, and not 
introduce features," and if that's not something we care about as a 
principle, then the policy shouldn't say that we do.  That's my 
argument: we should present users with realistic expectations of what 
the distribution will deliver.




However it already allows exceptions when updating to a new
major release is necessary to maintain security



That's also true.  The policy does allow updating for security reasons, 
but it also says of those updates that "the package maintainer(s) MUST 
open a FESCo ticket for approval to rebase".




On the whole, I'd say the policy is still sensible as-is, but it's
always been something that's kind of applied on request, like city
bylaws tend to be. If your garden fence is against the bylaws but none
of your neighbours complain, you'll probably get away with it. If you
update your package to a new major release but everyone who uses it is
fine with that, you'll probably get away with it...we tend to only
invoke the policy when an update gets "flagged" by negative feedback or
a failed test or whatever.



I'll keep beating the Thunderbird drum: On Sep 2, a thread started on 
this list re: "Thunderbird 102 pushed to F36 stable." As far as I know, 
no action was taken in response to users reporting that a major update 
pushed during a stable release broke their workflow.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

On 2022-11-24 05:50, Tomáš Popela wrote:
Although not explicitly stated there, Firefox is mentioned as a first 
example in 
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#examples. 
Also nearly all Firefox and Thunderbird updates there are the security 
ones there really isn't another way (unless someone will package 
Firefox ESR releases in Fedora, but that would need to be rebased 
yearly anyway).



Yes, Firefox appears as an example, but my reading is that it's an 
example of the class of packages that fall under the "Security fixes" 
category, which states that "the package maintainer(s) MUST open a FESCo 
ticket for approval to rebase the package".  I don't think that's 
happening for each Firefox release (nor would that really be practical), 
which is why it stands out as weird that I can't find a FESCO ticket 
granting Firefox a permanent exception.


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes

Thunderbird is a case where I'd like to see a specific update policy 
decision.  It follows the Mozilla ESR schedule, so a release is 
supported for a little over a year.  Given Fedora's release schedule, it 
would need to be updated to a new major version in at least alternating 
Fedora releases.  But there's 12 weeks of overlap from one supported 
release to the next.  I see Thunderbird as a business productivity suite 
that offers an API for integrations (which can break from one release to 
the next), similar to LibreOffice (which, as far as I know, Fedora does 
not rebase during a release).  And because the API is not guaranteed to 
be compatible from one release to the next, I would much prefer to see 
Thunderbird updated early in Rawhide and releases that are not yet 
final, but to remain on the older stable version for as long as possible 
on any Fedora release that had included it.  As it is today, users get 
breaking changes in Thunderbird at unexpected times.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)

[Maxwell G via devel]

On Thu Nov 10, 2022 at 15:23 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
>
> The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`.
> When an RPM package is built, mtimes of packaged files will be clamped
> to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest
> `%changelog` entry. As a result, more RPM packages will be
> reproducible: The actual modification time of files that are e.g.
> modified in the `%prep` section or built in the `%build` section will
> not be reflected in the resulting RPM packages. Files in RPM packages
> will have mtimes that are independent of the time of the actual build.
>

Will packagers still be required to use install -p, cp -p, etc. to
preserve mtimes? For some packages, the source archives mtimes will be
lower than $SOURCE_DATE_EPOCH, but e.g. for ancillary Source files (e.g.
systemd units) stored in distgit, using -p won't make a difference,
because the mtimes aren't preserved when Koji clones the distgit
repository.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Maxwell G via devel]

On Thu Nov 24, 2022 at 12:25 +0100, Miro Hrončok wrote:
> On 24. 11. 22 3:38, Maxwell G via devel wrote:
> > On Thu Nov 24, 2022 at 02:39 +0100, Miro Hrončok wrote:
> >> go-compilers
> >> go-srpm-macros
> > 
> > These should both be orphaned. go-srpm-macros has been retired, as it's
> > now a subpackage of go-rpm-macros.
>
> But it exists on Fedora 36 and needs a maintainer there. It will likely be 
> auto-orphaned once Fedora 36 EOLs. Should I give it to you?


It's not part of the Fedora 36 composes, because go-rpm-macros's
go-srpm-macros subpackage has a higher NEVR, but feel free to assign it
to me.

>
> > go-compilers is Obsoleted by
> > go-rpm-macros itself, but it looks like it has not yet been retired.
> > I've gone ahead and done that. This split happened a few years ago, but
> > the old packages were never properly removed.
>
> Ack. Technically also needs a maintainer but less important considering ti is 
> obsoleted. Users do report bugzillas for whatever component, so I do 
> recommend 
> having a responsive/responsible bugzilla PoC even for this one.

You can also assign this one to me.


--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Adam Williamson]

On Thu, 2022-11-24 at 07:34 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
> > In the wild, I often see Fedora described as a "semi-rolling" release. As a
> > policy matter, the distribution promises to be mostly stable, but I find it
> > increasingly hard to honestly present it as such.
> > 
> > As a couple of quick examples, I'd point out that in Fedora 35, Blender
> > updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
> > updated from version 27 to 28.  I've read in the KDE Matrix channel that KDE
> > will be updated in Fedora 36 to 5.26, even though it has already been
> > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
> > Fedora used to update all releases with every KDE release, but decided to
> > stop).  Firefox and Thunderbird get updates in most releases, even when they
> > contain API-breaking changes  (those really should have an explicit
> > exception, IMHO.)  I could offer more, but my point is simply that examples
> > of updates in prominent packages isn't hard to find.
> 
> FWIW, I was sure that we have an explicit exception for Firefox. But
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
> doesn't list it.
> 
> Yeah, I think that the way updates are managed has in practice changed a lot.
> This is at least partially caused by the slow change in relationship between
> upstreams and our packaging: the distro is inching ever closer to being a
> thin delivery mechanism for upstream code and upstream build system and
> upstream packaging decisions and upstream release cadence. Even a few years
> ago it was fairly common for the packaging to be a big affair with tweaks
> to the upstream build system or even a completely custom build, downstream
> patches, and many modifications to the final layout. There still are packages
> like this, but less and less. If the upstream is sane, there is no need to
> deal with any of that.
> 
> Another aspect that has changed is that many upstreams are better at keeping
> backwards compatibility. E.g. in Rust and Python ecosystems, semver is now
> the norm, and in my experience the associated understanding that breaking API
> is bad is more widespread. So there are less reasons for us not to update.
> At the same time, software is ever more complicated and moves ever faster,
> so maintaining multiple versions in parallel is a lot of work.
> 
> Combining all that (bigger and more complicated packages, saner upstream
> updates, and our packaging being closer to upstream), just makes it less
> work for the packager to release the same upstream version in all Fedora
> releases.
> 
> Then there's the aspect that for fast-moving software, the latest version
> may be the only usable version.
> 
> > That's not necessarily to object to those changes (though I did have to do
> > some minor fixes after the emacs update, and I grumbled quietly), and I
> > don't want to disrupt users getting new features if that's what everyone
> > actually wants.  But, it does bother me that the documentation doesn't seem
> > to reflect reality.  I think that the documentation should offer users a
> > realistic expectation of what they'll get from Fedora.
> > 
> > Does anyone else feel like the documentation should be updated, or am I
> > making too much of this?
> 
> I think the documentation should be updated to follow the changing practice.
> I'd change the policy to allow packages to update to latest versions
> if deemed the best option by the maintainers. (Guidance when it is
> actually the best option would need to be provided too of course.)

Well, I find your mail interesting, because...I agree with most of the
first paragraph, but at the same time, none of that is really in
conflict with the existing update policy as I read it.

The update policy is very keen on discouraging *compatibility-breaking*
updates. However it already allows exceptions when updating to a new
major release is necessary to maintain security (i.e. upstream doesn't
provide stable branches with security fixes, and backporting downstream
is too difficult).

The thrust of your argument is that the F/OSS ecosystem as a whole has
gotten better at doing updates that don't break compatibility. It's not
against the current policy, as I read it, to ship such updates, so it
doesn't really need any updating on that view...

On the whole, I'd say the policy is still sensible as-is, but it's
always been something that's kind of applied on request, like city
bylaws tend to be. If your garden fence is against the bylaws but none
of your neighbours complain, you'll probably get away with it. If you
update your package to a new major release but everyone who uses it is
fine with that, you'll probably get away with it...we tend to only
invoke the policy when an update gets "flagged" by negative feedback or
a failed test or whatever.

I also have a confession like msuchy's: I don't follow the 

Re: Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

On 2022-11-24 03:13, Michael J Gruber wrote:

I guess there's (at least) two ways to understand "stable":

- things don't break
- things don't change



True, but the policy document is explicit about which meaning is 
intended, reading, "Updates should aim to fix bugs, and not introduce 
features, particularly when those features would materially affect the 
user or developer experience"


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Ask Fedora: user reporting trouble with R-pi 4. Could someone please take a look?

[Ankur Sinha]

On Thu, Nov 24, 2022 16:22:02 +, Peter Robinson wrote:
> 
> I replied, but he doesn't actually provide much information to be able
> to actually reply with certainly.

Thanks. Yeh, it often takes a little bit of back and forth to obtain the
necessary info. I didn't know what to ask for, or I'd have started with
that already.


> Also may be better to send queries around arm to the arm list, I saw
> this by luck.

Unfortunately, I'm not an arm user myself, so I'm not the arm lists.
Would it be possible for some of the arm folks to look at the forum from
time to time please? It's noted as the official support channel on the
website, so it'll be the first place folks will come to.

We can point them to the arm list if that's preferred too. Please let us
know and I can announce it on the forum there so folks know.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Ask Fedora: user reporting trouble with R-pi 4. Could someone please take a look?

[Peter Robinson]

Hi,

> We've had a post this morning from a user having trouble with R-pi 4
> using the F37 ARM 64 images. Could someone with some experience in this
> area please take a look and maybe help them out?
>
> https://ask.fedoraproject.org/t/fedora-arm-64-does-not-work-on-raspberry-pi-4/29111

I replied, but he doesn't actually provide much information to be able
to actually reply with certainly.

Also may be better to send queries around arm to the arm list, I saw
this by luck.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Richard Shaw]

On Thu, Nov 24, 2022 at 9:12 AM Petr Pisar  wrote:

> V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a):
> > > > Does anyone else feel like the documentation should be updated, or
> > > > am I making too much of this?
> >
> > +1 to update documentation. Or even better, document which packages has
> the
> > exception. And later ask QE to create tool which will warn if packages
> > outside of this list bump up version.
> >
> Checking for a version bump does not make sense unless you want to force
> maintainers to backport each fix. (Nonpaid maintainers won't do it.)
>

+1000...

Also, I think keeping the version the same and adding a bunch of upstream
commits that essentially makes it the new version is fundamentally
dishonest. Plus if you do need to report a bug upstream, which version is
it? There's not really an option for "Frankenstein".

My packaging philosophy has largely been, try not to perform soname bumps
in released versions unless absolutely necessary, and most people want the
latest version of user facing apps.

Also, most upstreams of my user facing app packages release incrementally
and frequently. If I didn't update them, I could easily be 10 releases
behind between Fedora releases. That doesn't make sense.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Petr Pisar]

V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a):
> > > Does anyone else feel like the documentation should be updated, or
> > > am I making too much of this?
> 
> +1 to update documentation. Or even better, document which packages has the
> exception. And later ask QE to create tool which will warn if packages
> outside of this list bump up version.
> 
Checking for a version bump does not make sense unless you want to force
maintainers to backport each fix. (Nonpaid maintainers won't do it.)

Many upstreams release bug-fix only versions. It's easier for everyone to take
that new version and place it into stable Fedora than applying the difference
as a patch or cherry-picking various commits from an upstream version
controll sysmte (if there is some). Example is a Perl bump from 5.34.0 to
5.34.1. Also many times you cannot distinguish a bug-fix update from
a breaking change by looking at the version number. Example from perl-YAML
changelog:

1.30 Mon 27 Jan 2020 11:09:46 PM CET
 - Breaking Change: Set $YAML::LoadBlessed default to false to make it more
   secure

1.29 Sat 11 May 2019 10:26:54 AM CEST
 - Fix regex for alias to match the one for anchors (PR#214 TINITA)

1.28 Sun 28 Apr 2019 11:46:21 AM CEST
 - Security fix: only enable loading globs when $LoadCode is set (PR#213
   TINITA)


It's not only about bug fixes. In the past I was strict in not adding new
version to stable Fedoras. But I was smashed by users and packagers requesting
rebases there. Either because of new features or just only because of the
version numbers because a third-party code checks for a minimal version.
So I ended up actively rebasing packages until a breaking change. I found it
less error prone to evaluate each update as it comes, than keep everything
boilig in Rawhide and than evaluate a lump of interdependent packages once
in a long time. Especially if the interdependencies are not obvious.

Based on these observations I'm against placing a machine blindly rejecting
version bumps.

That does not mean I encourage maintainers to blindly rabase in stable
Fedoras. If they don't feel confident, then they should not do the rebase.

However, to increase the confidence and quality of Fedora updates, I'd rather
see enforcing fedora-ci tests in Bodhi. They already checks changes in RPM
dependencies, changes in shared library ABI, breaking upgrade path etc. An
example . It's
really pitty we do not have these tests globally enabled.

People do mistakes, but it does not mean we should stop updating
a distribution because of that.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/24/22 08:45 AM, Kalev Lember wrote:

Hi Scott,

On Wed, Nov 23, 2022 at 6:23 PM Scott Talbert mailto:s...@techie.net>> wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
currently built with OpenGL EGL support) and several package users which
are expecting OpenGL GLX support, I need to rebuild wxWidgets with a
different configuration option.  Unfortunately, this results in an ABI
change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be
rebuilt.  Unfortunately #2, this also needs to be done in F37.  I've
opened two side tags to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198

The following packages need to be rebuilt in the above side tags (note,
I've already taken care of python-wxpython4 and CubicSDR, which are also
affected):

0ad


I did 0ad rebuilds for both F37 and F38:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092061 

F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092060 



The KiCad builds are also complete:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092087
F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092086

Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

[rpms/perl-Convert-BER] PR #2: Fix test package and BuildRequires

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Convert-BER` that 
you are following:
``
Fix test package and BuildRequires
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Convert-BER/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Tomáš Popela]

On Thu, Nov 24, 2022 at 2:34 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
> > In the wild, I often see Fedora described as a "semi-rolling" release.
> As a
> > policy matter, the distribution promises to be mostly stable, but I find
> it
> > increasingly hard to honestly present it as such.
> >
> > As a couple of quick examples, I'd point out that in Fedora 35, Blender
> > updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
> > updated from version 27 to 28.  I've read in the KDE Matrix channel that
> KDE
> > will be updated in Fedora 36 to 5.26, even though it has already been
> > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
> > Fedora used to update all releases with every KDE release, but decided to
> > stop).  Firefox and Thunderbird get updates in most releases, even when
> they
> > contain API-breaking changes  (those really should have an explicit
> > exception, IMHO.)  I could offer more, but my point is simply that
> examples
> > of updates in prominent packages isn't hard to find.
>
> FWIW, I was sure that we have an explicit exception for Firefox. But
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
> doesn't list it.
>
>
Although not explicitly stated there, Firefox is mentioned as a first
example in
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#examples. Also
nearly all Firefox and Thunderbird updates there are the security ones
there really isn't another way (unless someone will package Firefox ESR
releases in Fedora, but that would need to be rebased yearly anyway).

Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Kalev Lember]

Hi Scott,

On Wed, Nov 23, 2022 at 6:23 PM Scott Talbert  wrote:

> Hi all,
>
> In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
> currently built with OpenGL EGL support) and several package users which
> are expecting OpenGL GLX support, I need to rebuild wxWidgets with a
> different configuration option.  Unfortunately, this results in an ABI
> change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be
> rebuilt.  Unfortunately #2, this also needs to be done in F37.  I've
> opened two side tags to do the rebuilds for F37 and F38.
>
> F37: f37-build-side-60200
> F38: f38-build-side-60198
>
> The following packages need to be rebuilt in the above side tags (note,
> I've already taken care of python-wxpython4 and CubicSDR, which are also
> affected):
>
> 0ad
>

I did 0ad rebuilds for both F37 and F38:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092061
F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092060

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Miroslav Suchý]

Dne 24. 11. 22 v 9:52 Vít Ondruch napsal(a):
I think that the documentation is right and should be honored. 


For the audience - the documentation is here:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy


Updates in stable should be exception, if there really is no other option.


Yup. It is even documented there:

"Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, 
but you think it should be allowed to update more rapidly, propose a new exception class to FESCo and/or request an 
exception for your specific update case."


I have to make confession. I am breaking this guidelines too. With releasing of new version of Mock and 
fedora-license-data. The problem for me is that the list of these exception is not available and not maintained. I 
inherited Mock from Clark and later gave it to Pavel and I am now merely co-maintainer. So I really do not know if Mock 
has had the exception. And because no one enforce it I even did not apply for the exception for fedora-license-data and 
I use common sense, becase it does not have sense to have old data in stable branches.



Does anyone else feel like the documentation should be updated, or am I making too much of this? 


+1 to update documentation. Or even better, document which packages has the exception. And later ask QE to create tool 
which will warn if packages outside of this list bump up version.


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Ask Fedora: user reporting trouble with R-pi 4. Could someone please take a look?

[Ankur Sinha]

Hi folks,

We've had a post this morning from a user having trouble with R-pi 4
using the F37 ARM 64 images. Could someone with some experience in this
area please take a look and maybe help them out?

https://ask.fedoraproject.org/t/fedora-arm-64-does-not-work-on-raspberry-pi-4/29111

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Vít Ondruch]

Dne 24. 11. 22 v 12:13 Michael J Gruber napsal(a):

I guess there's (at least) two ways to understand "stable":

- things don't break
- things don't change

(... unless absolutely necessary, in each case)

To me, "things don't break" describes Fedora stable releases (as opposed to rawhide), and 
"things don't change" describes RHEL.

A typical Fedora user wants the latest if it works and should be prepared to 
adjust to the changes this brings with it



I disagree here. And even if you are right at this point, then they 
could wait 6 months for next Fedora release, can't they?



Vít



  (but not to rawhide-type breakage). A typical RHEL user wants a stable 
environment for reproducible computing (short of containerizing and freezing 
for reproducibility).

On a side-note: This is why Fedora packagers are sometimes hesitant to build for EPEL 
because it means going by a different notion of "stable".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Fedora rawhide compose report: 20221124.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221123.n.1
NEW: Fedora-Rawhide-20221124.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   17
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   175.20 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   382.97 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20221123.n.1.ppc64le.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  advancecomp-2.4-1.fc38
Old package:  advancecomp-2.3-3.fc38
Summary:  Recompression utilities for .png, .mng, .zip and .gz files
RPMs: advancecomp
Size: 653.63 KiB
Size change:  2.62 KiB
Changelog:
  * Thu Sep 29 2022 Benjamin A. Beasley  2.3-4
  - Add a comment about upstream tests

  * Thu Sep 29 2022 Benjamin A. Beasley  2.3-5
  - Identify bundled 7-Zip as ???7zip??? rather than ???7z???

  * Wed Nov 23 2022 Benjamin A. Beasley  2.4-1
  - Update to 2.4 (close RHBZ#2145023)
  - Security fix for CVE-2022-35014, CVE-2022-35015, CVE-2022-35016,
CVE-2022-35017, CVE-2022-35018, CVE-2022-35019, CVE-2022-35020


Package:  aime-8.20221121-1.fc38
Old package:  aime-8.20221031-1.fc38
Summary:  An application embeddable programming language interpreter
RPMs: aime aime-devel
Size: 3.64 MiB
Size change:  53.82 KiB
Changelog:
  * Thu Nov 24 2022 Filipe Rosset  - 8.20221121-1
  - Update to 8.20221121 fixes rhbz#2145128


Package:  ansible-7.0.0-1.fc38
Old package:  ansible-7.0.0~rc1-1.fc38
Summary:  Curated set of Ansible collections included in addition to 
ansible-core
RPMs: ansible
Size: 43.25 MiB
Size change:  -3.99 KiB
Changelog:
  * Wed Nov 23 2022 Maxwell G  - 7.0.0-1
  - Update to 7.0.0.


Package:  chatterino2-2.3.5-6.fc38
Old package:  chatterino2-2.3.5-3.fc37
Summary:  Chat client for twitch.tv
RPMs: chatterino2
Size: 10.60 MiB
Size change:  23.23 KiB
Changelog:
  * Thu Nov 24 2022 Artem Polishchuk  2.3.5-5
  - build: Add Requires: qt5-qtsvg

  * Thu Nov 24 2022 Artem Polishchuk  2.3.5-6
  - build: ExcludeArch: %{ix86}


Package:  gcl-2.6.13-0.129.fc38
Old package:  gcl-2.6.13-0.126.fc38
Summary:  GNU Common Lisp
RPMs: gcl gcl-emacs
Size: 23.07 MiB
Size change:  -34.63 KiB
Changelog:
  * Wed Nov 23 2022 Jerry James  - 2.6.13-0.129
  - Update to 2.6.13pre129
  - Add patch for https://fedoraproject.org/wiki/Changes/PortingToModernC
  - Silence warnings about the obsolescence of egrep and fgrep


Package:  libbsd-0.11.7-1.fc38
Old package:  libbsd-0.10.0-10.fc37
Summary:  Library providing BSD-compatible functions for portability
RPMs: libbsd libbsd-ctor-static libbsd-devel
Size: 1.60 MiB
Size change:  82.60 KiB
Changelog:
  * Thu Nov 24 2022 Robert Scheck  - 0.11.7-1
  - Update to 0.11.7 (#1742611)


Package:  mpfr-4.1.1-2.fc38
Old package:  mpfr-4.1.1-1.fc38
Summary:  C library for multiple-precision floating-point computations
RPMs: mpfr mpfr-devel mpfr-doc
Size: 3.00 MiB
Size change:  1.41 KiB
Changelog:
  * Wed Nov 23 2022 Jerry James  - 4.1.1-2
  - Update to MPFR 4.1.1-p1


Package:  parallel-20221122-1.fc38
Old package:  parallel-20221022-1.fc38
Summary:  Shell tool for executing jobs in parallel
RPMs: parallel
Size: 415.01 KiB
Size change:  1.85 KiB
Changelog:
  * Thu Nov 24 2022 Filipe Rosset  20221122-1
  - updated to latest version


Package:  picom-10.1-2.fc38
Old package:  picom-10.1-1.fc38
Summary:  Lightweight compositor for X11
RPMs: picom
Size: 868.05 KiB
Size change:  1.12 KiB
Changelog:
  * Thu Nov 24 2022 Artem Polishchuk  10.1-2
  - build: Add upstream pcre2 patch


Package:  python-ansible-runner-2.3.1-1.fc38
Old package:  python-ansible-runner-2.2.1-2.fc37
Summary:  A tool and python library to interface with Ansible
RPMs: python3-ansible-runner
Size: 178.13 KiB
Size change:  139 B
Changelog:
  * Wed Nov 23 2022 Dan Radez  - 2.3.1-1
  - update to 2.3.1 (rhbz#2139251)


Package:  python-markdown-include-0.8.0-1.fc38
Old package:  python-markdown-include-0.6.0-14.fc37
Summary:  A Python-Markdown extension which provides an 'include' function
RPMs: python3-markdown-include
Size: 30.53 KiB
Size change:  1.50 KiB
Changelog:
  * Thu Nov 24 2022 Benjamin A. Beasley  0.6.0-15
  - Update License to SPDX

  * Thu Nov 24 2022 Benjamin A. Beasley  0.8.0-1
  - Update to 0.8.0


Package:  python-trezor-0.13.4-1.fc38
Old package:  python-trezor-0.13.3-3.fc37
Summary:  Python library for communicating with TREZOR Hardware Wallet
RPMs: python3-trezor
Size: 556.25 KiB
Size change

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Daniel P . Berrangé]

On Thu, Nov 24, 2022 at 12:35:43PM +0100, Miro Hrončok wrote:
> On 23. 11. 22 18:44, Daniel P. Berrangé wrote:
> > IMHO we would be better off eliminating the notion of 'main admin'
> > entirely and have all co-maintainers be at the equal level, so there
> > is no need for a dance to give packages to comaintainers. There
> > should only be manual action needed if the last comaintainer quits.
> 
> The bugzilla default assignee notwithstanding, I am afraid that this would
> create 2 more problems:
> 
> 1) I've seen packages with 15+ nonrepsonsive co-maintainers. Currently I am
> glad that I can "just" process 1 non-responsive maintainer thing to get it
> orphaned. If a new maintainer takes it, they can clean the ACL cruft. And if
> an old maintainer takes it, at lest now they are the ones with
> "responsibility". If nobody takes it, it gets retired and the ACLs are moot.
> win-win-win. How would this work in this "common ownership" scheme?

The non-responsive maintainer process isn't inherantly tied to
individuals though. The thing is kicked off with filing a bug
against the package asking for a response, and escalates from
there until either there is a response or the package gets
orphaned. Whether 1 maintainer is responsible for ack'ing the
bug, or any of the co-maintainers can ack it feels pretty minor.

> 2) I've seen packages maintained by groups. If the group does not regularly
> triage their bugzillas or if all of the bugzillas are not miraculously
> solved by one "hero", such buzgillas tend to rot. Everybody assumes the
> others are responsible. Many group members don't even read bugzilla email
> for their group. Often, FAS accounts of long-gone folks are assigned as
> admins and the group is set as the main bugzilla contact. This makes
> contacting somebody who will care extremely hard for a bug reporter. (I've
> also seen groups where this works well, but they are usually either very
> well organized or 1-person groups.)

Of course there's never any gaurantee that bugs will get a
response. That's true whether there's a main maintainer with
several co-maintainers, or simply many co-maintainers as peers.

There's nothing special about Fedora packages in this respect,
it is true of all upstream projects too. Bugs are always the
collective responsibility of every maintainer, and unless a
project has a nominated bug triage person, it is not good to
assign all bugs to a specific person. If anything it will make
it less likely to get a response if all bugs get pushed to just
one person, out of many as it isn't scalable.

In terms of FAS accounts who are long gone, that's not an argument
for avoiding a collective maintainer concept. The focus needs to
on identifying accounts who've had no activity in Fedora and
deactivating them and removing them from package maint at some
point, to reduce risk of idle account takeover. This could start
with a reminder alert to the list of maintainers for a package
asking them if idle maintainers still need to retain privileges,
encouraging them to remove dormant accounts. This group self
purging of dormant acocunt would be easier without the 'main admin'
concept that requires the hand over dance

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 23. 11. 22 18:44, Daniel P. Berrangé wrote:

IMHO we would be better off eliminating the notion of 'main admin'
entirely and have all co-maintainers be at the equal level, so there
is no need for a dance to give packages to comaintainers. There
should only be manual action needed if the last comaintainer quits.


The bugzilla default assignee notwithstanding, I am afraid that this would 
create 2 more problems:


1) I've seen packages with 15+ nonrepsonsive co-maintainers. Currently I am 
glad that I can "just" process 1 non-responsive maintainer thing to get it 
orphaned. If a new maintainer takes it, they can clean the ACL cruft. And if an 
old maintainer takes it, at lest now they are the ones with "responsibility". 
If nobody takes it, it gets retired and the ACLs are moot. win-win-win. How 
would this work in this "common ownership" scheme?


2) I've seen packages maintained by groups. If the group does not regularly 
triage their bugzillas or if all of the bugzillas are not miraculously solved 
by one "hero", such buzgillas tend to rot. Everybody assumes the others are 
responsible. Many group members don't even read bugzilla email for their group. 
Often, FAS accounts of long-gone folks are assigned as admins and the group is 
set as the main bugzilla contact. This makes contacting somebody who will care 
extremely hard for a bug reporter. (I've also seen groups where this works 
well, but they are usually either very well organized or 1-person groups.)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 24. 11. 22 3:38, Maxwell G via devel wrote:

On Thu Nov 24, 2022 at 02:39 +0100, Miro Hrončok wrote:

go-compilers
go-srpm-macros


These should both be orphaned. go-srpm-macros has been retired, as it's
now a subpackage of go-rpm-macros.


But it exists on Fedora 36 and needs a maintainer there. It will likely be 
auto-orphaned once Fedora 36 EOLs. Should I give it to you?



go-compilers is Obsoleted by
go-rpm-macros itself, but it looks like it has not yet been retired.
I've gone ahead and done that. This split happened a few years ago, but
the old packages were never properly removed.


Ack. Technically also needs a maintainer but less important considering ti is 
obsoleted. Users do report bugzillas for whatever component, so I do recommend 
having a responsive/responsible bugzilla PoC even for this one.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Michael J Gruber]

I guess there's (at least) two ways to understand "stable":

- things don't break
- things don't change

(... unless absolutely necessary, in each case)

To me, "things don't break" describes Fedora stable releases (as opposed to 
rawhide), and "things don't change" describes RHEL.

A typical Fedora user wants the latest if it works and should be prepared to 
adjust to the changes this brings with it (but not to rawhide-type breakage). A 
typical RHEL user wants a stable environment for reproducible computing (short 
of containerizing and freezing for reproducibility).

On a side-note: This is why Fedora packagers are sometimes hesitant to build 
for EPEL because it means going by a different notion of "stable".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: python-pyupgrade is orphaned

[Onuralp SEZER]

You're welcome, F36,F37,F38 versions are done If you need it, They are all
ready to use :)

Thank you
Onuralp.

--
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Türkiye
Fedora Translations Turkish Team Member

Fedora KDE Sig Member 
Fedora Website and Apps Mindshare Member

Fedora Design Member 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: python-pyupgrade is orphaned

[Roman Inflianskas via devel]

Thanks for taking it and updating to a new version so quickly.

On Thu, Nov 24, 2022 at 11:13 AM Onuralp SEZER <
thunderbir...@fedoraproject.org> wrote:

> Hello, I take it and any other co-maintainer is also welcome as well.
>
> On Thu, Nov 24, 2022 at 11:54 AM Roman Inflianskas via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Hi,
>>
>> I've orphaned python-pyupgrade because of lack of the time and because I
>> don't use it anymore.
>>
>> Caution: this package updates quite frequently, sometimes once per a few
>> days.
>>
>> --
>> [image: Aiven] 
>> *Roman Inflianskas*
>> Software Engineer, *Aiven*
>> rom...@aiven.io   |  +358 503455168
>> aiven.io    |
>> 
>> 
>> 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@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
>>
>
>
> --
>
>
>
>
>
> --
> Onuralp SEZER
> Fedora Ambassadors  EMEA
>  Member / Turkey
> Fedora Translations Turkish Team Member
> 
> Fedora Design Member 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>


-- 
[image: Aiven] 
*Roman Inflianskas*
Software Engineer, *Aiven*
rom...@aiven.io   |  +358 503455168
aiven.io    |


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Karolina Surma]

On 11/16/22 08:58, Zbigniew Jędrzejewski-Szmek wrote:


Hello,

The standard invocation of the Python dependency generator will be
changed to always run with option like `--fail-if-version-zero`. (This
is the subject of the current proposal.)

Based on your concerns, an opt out mechanism would be added:
If you wanted to bypass the option, you could define a macro in the
specfile, eg.
`%{!?__python_dist_allow_version_zero:--fail-if-version-zero}`

This would allow to build RPMs without bothering with versions. Also, if
it's upstream's decision to use version 0, that would be the way to go.
In Fedora this would give us an insight into how often this is needed.

What do you think of enhancing the proposal this way?


This would provide the opt-out that was requested.

But it's also very specific to a problem that is mostly theoretical.
Maybe instead add %__python_dist_extra_flags that would contain 
'--fail-if-version-zero'
by default. That would also provide an opt-out, but allow other
currently unforeseen uses.

Zbyszek


Thank you for the alternative proposal. After discussion with Miro 
Hrončok we decided for the initial idea of a macro which if defined, 
will disable the flag from script invocation.
The main reason being that there's already another Python macro that 
behaves this way 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_python_no_extras_requires), 
so the new one will fit into the picture.

It'll be also easily greppable for usage statistics.
As we expect little to no need to actually use the opt-out, the trivial 
(to implement and use) solution seems just enough.


Karolina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: python-pyupgrade is orphaned

[Onuralp SEZER]

Hello, I take it and any other co-maintainer is also welcome as well.

On Thu, Nov 24, 2022 at 11:54 AM Roman Inflianskas via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
> I've orphaned python-pyupgrade because of lack of the time and because I
> don't use it anymore.
>
> Caution: this package updates quite frequently, sometimes once per a few
> days.
>
> --
> [image: Aiven] 
> *Roman Inflianskas*
> Software Engineer, *Aiven*
> rom...@aiven.io   |  +358 503455168
> aiven.io    |
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>


-- 





--
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Turkey
Fedora Translations Turkish Team Member

Fedora Design Member 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F38 proposal: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)

[Karolina Surma]

On 11/14/22 16:35, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Prevent-Providing-python3dist(pkg)%3D0

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
It sometimes happens that Python packages succeed to build as RPM with
incorrect version metadata.
They generate a wrong provide in format `python3dist(...) = 0` and
`python3.Xdist(...) = 0`.
While version `0` (or equal versions like `0.0` or `0.0.0`) is
probably technically valid, in most cases this indicates a packaging
error.
We propose to prevent this error from happening by explicitly failing
the RPM build instead of generating such provides.

== Owner ==
* Name: [[User:Ksurma|Karolina Surma]]
* Email: ksu...@redhat.com


== Detailed Description ==
This change is about automatic RPM provides in the following form:

* `python3dist(distname) = 0`
* `python3.Xdist(distname) = 0`

Where X is the Python minor version (eg. 10, 11...).
It does not affect any other provides.
More about these provides:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-readable-provides

The provides generated during the RPM build come from the upstream
Python package metadata.
Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.

In other cases, for example when building package from a particular
git commit, the incorrect provide can be generated due to a packaging
error.
We've never encountered a situation when packaging the version `0` was
the package maintainers intention.
After a discussion on python-devel mailing list we agreed we'd like to
prevent such situations from happening in Fedora.

An example of the incorrect provides:

  $ rpm -qpP python3-ssh-python-0.10.0-5.fc38.x86_64.rpm
  python-ssh-python = 0.10.0-5.fc38
  python3-ssh-python = 0.10.0-5.fc38
  python3-ssh-python(x86-64) = 0.10.0-5.fc38
  python3.11-ssh-python = 0.10.0-5.fc38
  '''python3.11dist(ssh-python) = 0'''
  '''python3dist(ssh-python) = 0'''

Why is it bad?

If any package requires `python3-ssh-python > 0.9` (correctly assuming
there's `0.10.0` in Fedora's repositories), the automatic dependency
generators will not discover the example package, making the other
package non-installable.

In January 2022 the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0
umbrella Bugzilla ticket] was created for Python packages providing
version `0`. In all cases the automatic provide wasn't intended.

Affected packages (as of Nov 11 2022):

  b43-tools
  dionaea
  marisa
  python-podman-api
  rpkg
  spectrographic
  python-ssh-python
  python-streamlink

The change doesn't affect a big part of the Python ecosystem.

We aim to prevent such situation from happening by increasing the
robustness of the python-rpm-generators (namely
[https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
pythondistdeps.py]).
The generator will error and fail the build if `python3dist(...) = 0`
was to be generated.

Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.
Packagers who encounter such need are encouraged to work with upstream
to set the version to at least `0.0.1`.

== Feedback ==
The idea was posted on
[https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/K35JCFVJLETVUOICQM634OSYBYQ3Q2WQ/
python-devel mailing list] and received a positive feedback. No
alternatives to this approach were proposed.

== Benefit to Fedora ==
The correct metadata is essential for the whole package ecosystem.
More deterministic behavior of the generators will bring those
benefits:
* The packages will stop lying about the version they provide.
* The requirements generators (eg. `%pyproject_buildrequires`) will
correctly evaluate the Build- and Runtime Requirements based on the
correct Provides.
* The package maintainers who BuildRequire `%{py3dist pkgname} >= 0.2`
in their specfiles will always require the correctly evaluated
version.

== Scope ==
* Proposal owners:
# implement & test the change in python-rpm-generators
([https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py
pythondistdeps.py])

* Other developers:
** Fix the packaging error to generate correct metadata and successful
build. There's no common way to deal with such packages. In most of
the cases the issue originates from packaging errors that need to be
fixed. Contact the change owners if you need help with the necessary
changes to your package.

* Release engineering: not 

python-pyupgrade is orphaned

[Roman Inflianskas via devel]

Hi,

I've orphaned python-pyupgrade because of lack of the time and because I
don't use it anymore.

Caution: this package updates quite frequently, sometimes once per a few
days.

-- 
[image: Aiven] 
*Roman Inflianskas*
Software Engineer, *Aiven*
rom...@aiven.io   |  +358 503455168
aiven.io    |


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Should the policy documents better reflect real package maintenance practice?

[Vít Ondruch]

I think that the documentation is right and should be honored. Updates 
in stable should be exception, if there really is no other option. I 
don't think that the constant churn of the updates is good for users and 
I think it'd be better if maintainers spend their time making sure the 
next version of Fedora is much better then keeping the older versions 
updated with the most recent versions.


But I am Rawhide user, so what can I know :)


Vít


Dne 24. 11. 22 v 1:04 Gordon Messmer napsal(a):
In the wild, I often see Fedora described as a "semi-rolling" release. 
As a policy matter, the distribution promises to be mostly stable, but 
I find it increasingly hard to honestly present it as such.


As a couple of quick examples, I'd point out that in Fedora 35, 
Blender updated from 2.93 (an LTS version) to version 3.  In Fedora 
36, Emacs updated from version 27 to 28.  I've read in the KDE Matrix 
channel that KDE will be updated in Fedora 36 to 5.26, even though it 
has already been updated from 5.24 -> 5.25 (my reading of the KDE 
update policy is that Fedora used to update all releases with every 
KDE release, but decided to stop).  Firefox and Thunderbird get 
updates in most releases, even when they contain API-breaking changes  
(those really should have an explicit exception, IMHO.)  I could offer 
more, but my point is simply that examples of updates in prominent 
packages isn't hard to find.


That's not necessarily to object to those changes (though I did have 
to do some minor fixes after the emacs update, and I grumbled 
quietly), and I don't want to disrupt users getting new features if 
that's what everyone actually wants.  But, it does bother me that the 
documentation doesn't seem to reflect reality.  I think that the 
documentation should offer users a realistic expectation of what 
they'll get from Fedora.


Does anyone else feel like the documentation should be updated, or am 
I making too much of this?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

@Ben isn't it the time to finish this round?


Vít


Dne 18. 08. 22 v 23:28 Ben Cotton napsal(a):

Hello everyone!

I just completed the first run of FESCo's newly approved Inactive
Packager Policy[1]. Packagers that have been identified as inactive
have a ticket in the find-inactive-packagers repo[2]. One week after
the F37 final release, packagers who remain inactive will be removed
from the packager group. (Note that pagure.io is one of the systems
checked for activity, so commenting on your ticket that you're still
around will prevent you from showing up in the second round.)

Since this is the first time we've done something like this, it could
be a little rough. I appreciate your patience and understanding. If
you have suggestions for improvement, look for the open feature
issues[3] and file an issue in the find-inactive-packagers repo[4] if
it's not there already.

For the curious, here are the stats from today's run:

2550 users checked
913 of those had no activity on src.fedoraproject.org or pagure.io
835 of those had no activity in Bodhi
812 of those had no activity on the mailing lists
606 of those (~24% of packagers) had no activity in Bugzilla.

The script took a little under three hours to run.

[1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2] 
https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open
[3] https://pagure.io/find-inactive-packagers/issues?tags=feature
[4] https://pagure.io/find-inactive-packagers/new_issue



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Vít Ondruch]

Dne 23. 11. 22 v 21:05 Kevin Fenzi napsal(a):

On Wed, Nov 23, 2022 at 05:44:01PM +, Daniel P. Berrangé wrote:

The mitigation/successor strategy is to have comaintainers for every
package.

Unfortunately our tools enforce the notion of a "main admin" and
if that person leaves that role has to be given to another
comaintainer explicitly.



I don't disagree about the "main admin" think, but I think we've already 
been there. I remember that the unresponsive policy worked in a way that 
when the main contact was not responsive, the package was given to 
second co-maintainer in alphabetical order. And I can tell you this was 
frustrating having my user name starting with 'v'. And frustrating 
driving the unresponsive maintainer process just having the package 
given to another inactive maintainer.



Vít



Thats due to bugzilla really. bugzilla only supports assigning a bug to
1 account. ;(


IMHO we would be better off eliminating the notion of 'main admin'
entirely and have all co-maintainers be at the equal level, so there
is no need for a dance to give packages to comaintainers. There
should only be manual action needed if the last comaintainer quits.

+100


A workaround for the 'main admin' problem is to have a robot account
as the 'main admin' and all the real people as merely 'admin', so
the main admin never leaves, but that's a bit tedious to setup.

I agree, but it would be a good deal of work to switch to.

I'd definitely like to do this when/if we move away from bugzilla.

kevin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Vitaly Zaitsev via devel]

On 23/11/2022 18:44, Daniel P. Berrangé wrote:

IMHO we would be better off eliminating the notion of 'main admin'
entirely and have all co-maintainers be at the equal level, so there
is no need for a dance to give packages to comaintainers. There
should only be manual action needed if the last comaintainer quits.


+1

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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