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

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 >

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

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

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

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

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

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

Re: spin-kickstarts package

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.

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

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 > >

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

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 >

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

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 >> >

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

Fedora rawhide compose report: 20221124.n.0 changes

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

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

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

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

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

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

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

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

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

Re: python-pyupgrade is orphaned

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

Re: python-pyupgrade is orphaned

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 < >

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

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

Re: python-pyupgrade is orphaned

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

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

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

python-pyupgrade is orphaned

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

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

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

Re: Inactive packagers to be removed after the F37 release

@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

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

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

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

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