hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Thanks
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
To be honest, the patch was applied without any PR or bugzilla opened, just very simple inline comment, I don't really understand the patch.
That is why I did not submit it to upstream.
On Monday, 09 November 2020 at 14:23, Honggang LI wrote:
On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
To be honest, the patch was applied without any PR or bugzilla opened, just very simple inline comment, I don't really understand the patch.
That is why I did not submit it to upstream.
Can you be more specific? Which patch are you talking about? I can see only one patch in the package and it was committed by you: https://src.fedoraproject.org/rpms/rdma-core/c/55352ca3c535f31dfce9ab7779ee4...
Regards, Dominik
On Mon, Nov 09, 2020 at 02:39:22PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 09 November 2020 at 14:23, Honggang LI wrote:
On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
To be honest, the patch was applied without any PR or bugzilla opened, just very simple inline comment, I don't really understand the patch.
That is why I did not submit it to upstream.
Can you be more specific? Which patch are you talking about? I can see only one patch in the package and it was committed by you: https://src.fedoraproject.org/rpms/rdma-core/c/55352ca3c535f31dfce9ab7779ee4...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b Author: Peter Robinson pbrobinson@gmail.com Date: Tue Sep 15 00:26:18 2020 +0100
Split out libibverbs to a core sub package for libpcap IB support to minimise deps for users that don't require IB support
On 09/11/2020 14:50, Honggang LI wrote:
On Mon, Nov 09, 2020 at 02:39:22PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 09 November 2020 at 14:23, Honggang LI wrote:
On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
To be honest, the patch was applied without any PR or bugzilla opened, just very simple inline comment, I don't really understand the patch.
That is why I did not submit it to upstream.
Can you be more specific? Which patch are you talking about? I can see only one patch in the package and it was committed by you: https://src.fedoraproject.org/rpms/rdma-core/c/55352ca3c535f31dfce9ab7779ee4...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b Author: Peter Robinson pbrobinson@gmail.com Date: Tue Sep 15 00:26:18 2020 +0100
Split out libibverbs to a core sub package for libpcap IB support to minimise deps for users that don't require IB support
Well that's a packaging issue so it's not something that would normally go upstream, or does upstream have a spec file that you are using?
I mean I absolutely agree that it shouldn't have been done using PP powers without at least trying to talk to the package maintainers first if that is what happened, but it doesn't look like something where upstreaming is a concern.
Tom
On Mon, Nov 9, 2020 at 3:15 PM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
Well that's a packaging issue so it's not something that would normally go upstream, or does upstream have a spec file that you are using?
For this package there are upstream (prototype) spec files in the repo.
I don't know enough about the particulars in this case, but splitting out sub-packages to reduce the dependencies that are dragged in is often a good thing to accomplish in the grand scheme of things as part of minimization efforts.
Dne 09. 11. 20 v 15:50 Honggang LI napsal(a):
On Mon, Nov 09, 2020 at 02:39:22PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 09 November 2020 at 14:23, Honggang LI wrote:
On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote:
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI honli@redhat.com wrote:
hi
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
What I should to do with that commit? Just blindly revert it?
Send it upstream yourself. If you don't like the divergence, help fix it by sending the patch upstream and working with them.
To be honest, the patch was applied without any PR or bugzilla opened, just very simple inline comment, I don't really understand the patch.
That is why I did not submit it to upstream.
Can you be more specific? Which patch are you talking about? I can see only one patch in the package and it was committed by you: https://src.fedoraproject.org/rpms/rdma-core/c/55352ca3c535f31dfce9ab7779ee4...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b Author: Peter Robinson pbrobinson@gmail.com Date: Tue Sep 15 00:26:18 2020 +0100
Split out libibverbs to a core sub package for libpcap IB support to minimise deps for users that don't require IB support
While unfortunate this happened without communication, there is this guideline:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
Also minimizing package dependency chains possibly by splitting less common functionality into subpackage welcomed change.
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Nov 09, 2020 at 09:02:12PM +0800, Honggang LI wrote:
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
https://src.fedoraproject.org/rpms/rdma-core/c/59a8e2e0d0ddba785fc79c4731e0b...
It only changes how the software is packaged in Fedora, by making a separate libibverbs RPM package that can be installed separately from rdma-core. There is nothing to upstream since this is purely an RPM build change.
What I should to do with that commit? Just blindly revert it?
It seems useful to keep the change for minimizing unnecessary dependencies by consumers of the libibverbs library (such as the libpcap package mentioned in the commit).
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
So someone pinged me on IRC about this, I never saw the emails because you replied to the git commit and I auto archive/mute all those emails because I get a LOT of them. You never tried other communication mechanisms that I'm aware of such are IRC.
Also note there is no packaging requirements to get approval from package maintainers.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
The addition of libpcap linking against libibverbs pulled in a whole of extra dependencies that aren't used by Workstation/Cloud or anything that doesn't have infinband. So this just splits it out to a smaller package, for a IB user they will see nothing different.
I don't see how a spec file change is a "regression", there's nothing that will regress here, the rdma-core depends on the package and if anyone installs that they also get the new sub package, but if the general user doesn't have IB hardware, which is the vast majority of users even in the enterprise, they don't have to unnecessarily have extra stuff clogging up their system.
In terms of "upstream" I'm not sure what you mean there, because upstream of Fedora is generally tar files but do feel free to push the change upstream if you prefer that for managing stuff.
Peter
On 11/11/20 4:17 PM, Peter Robinson wrote:
Also note there is no packaging requirements to get approval from package maintainers.
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/
"Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes"
Yes, technically this is not a hard requirement, but a recommendation.
On Wed, Nov 11, 2020 at 03:17:47PM +0000, Peter Robinson wrote:
I'm one of package maintainers of rdma-core. There is a patch applied without any maintainers' review/approve. I had sent two emails to patch committer to ask him/her to push the change to upstream. But never get response.
So someone pinged me on IRC about this, I never saw the emails because you replied to the git commit and I auto archive/mute all those emails because I get a LOT of them. You never tried other communication mechanisms that I'm aware of such are IRC.
Also note there is no packaging requirements to get approval from package maintainers.
The patch maybe useful or fix something. But the divergence between upstream and Fedora rawhide is what I don't want to see, because such divergence is source of regression issues.
The addition of libpcap linking against libibverbs pulled in a whole of extra dependencies that aren't used by Workstation/Cloud or anything that doesn't have infinband. So this just splits it out to a smaller package, for a IB user they will see nothing different.
Split the package make sense. But you create a new sub-package with name "libibverbs-core". I don't agree with the new name. The original libibverbs package only includes the VERBs API library.
https://www.openfabrics.org/downloads/libibverbs/
In 2016, user-space drivers/providers, such as libmlx4, had been merged libibverbs. We may should keep libibverbs only includes the VERBs API library. And create a new sub-package as "libibverbs-providers". I will discuss this with upstream.
I don't see how a spec file change is a "regression", there's nothing
RHEL rdma-core builds are based on Fedora builds. Each time, when update upstream rdma-core for RHEL, I will pull changes from Fedora repo if such changes should be applied for RHEL too. The divergence between Fedora and upstream makes my work complicated.
I just checked RHEL-9 nightly build, the libibverbs-core package already in RHEL-9. I will have to handle this for RHEL-9.
that will regress here, the rdma-core depends on the package and if anyone installs that they also get the new sub package, but if the general user doesn't have IB hardware, which is the vast majority of users even in the enterprise, they don't have to unnecessarily have extra stuff clogging up their system.
In terms of "upstream" I'm not sure what you mean there, because
https://github.com/linux-rdma/rdma-core/blob/master/redhat/rdma-core.spec
It is the "upstream" spec file.
upstream of Fedora is generally tar files but do feel free to push the change upstream if you prefer that for managing stuff.
I will work with upstream to split the libibverbs package.
Peter _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, 2020-11-12 at 20:47 +0800, Honggang LI wrote:
In terms of "upstream" I'm not sure what you mean there, because
https://github.com/linux-rdma/rdma-core/blob/master/redhat/rdma-core.spec
It is the "upstream" spec file.
This kind of "oh, the *real* spec file is in another castle" approach is just impractical for distributions. It's always a problem, but it's *especially* a problem if the distribution spec file does not indicate the existence of the "upstream" spec in any way. As is the case here. You cannot expect another Fedora packager to look at https://src.fedoraproject.org/rpms/rdma-core/blob/master/f/rdma-core.spec and know that there is an "upstream" of that file, because *nothing in it tells them that there is*.
If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it.
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it.
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines? Something like:
If upstream provides SPEC files and your SPEC is a copy you should put on top of SPEC file: # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it.
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
Something like:
If upstream provides SPEC files and your SPEC is a copy you should put on top of SPEC file: # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote:
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it.
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
"If some maintainers are also attempting to keep copies of a spec in an outside repository, they MUST be prepared to merge changes made to the spec in Fedora’s repository, and MUST NOT overwrite those changes with a copy from an external repository or using fedpkg import."
→ this means that in principle is OK to if a maintainer wants to keep an "upstream" copy of the spec file, but it's their own problem to ferry the changes back to that upstream copy. The rules only say that they are not allowed to erase changes done by other packagers and releng.
If upstream provides SPEC files and your SPEC is a copy you should put on top of SPEC file: # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
But that doesn't change much. First, such a comment is not machine readable But even if we apply some pattern matching, we hit the second problem: anyone who is doing mass spec file updates (either releng or some provenpackager), has now way to make use of this information. They are not going to contact hundreds of upstreams to submit a cleanup fix. The only realistic solution is what the guidelines say: it's up to the maintainer of the package to ferry any changes back "upstream".
(More generally: what would the point of keeping an "upstream" spec file be? Either the spec file is only used by one distro, in which case everyone is better off if it's kept in the downstream repo. Or it's used by multiple distros, in which case we either have an über-complex spec file with %if-spaghetti or a spec file that doesn't fit any distro well, and again, everyone would be better of if the spec file were downstream.)
Zbyszek
Dne 16. 11. 20 v 10:22 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote:
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý msuchy@redhat.com wrote:
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec file...well, I wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec files need to have a clear explanation that there is an "upstream" spec file, with a justification as to why, and a link to it. At the very top. Otherwise there is no chance any other Fedora packager is going to find it.
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
"If some maintainers are also attempting to keep copies of a spec in an outside repository, they MUST be prepared to merge changes made to the spec in Fedora’s repository, and MUST NOT overwrite those changes with a copy from an external repository or using fedpkg import."
→ this means that in principle is OK to if a maintainer wants to keep an "upstream" copy of the spec file, but it's their own problem to ferry the changes back to that upstream copy. The rules only say that they are not allowed to erase changes done by other packagers and releng.
If upstream provides SPEC files and your SPEC is a copy you should put on top of SPEC file: # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
But that doesn't change much. First, such a comment is not machine readable
I should not propose this, because I agree with the points bellow. But if we should have it, then:
~~~
Provides: upstream-spec(https://some.url/to/upstream/package.spec)
~~~
would be machine readable and it would give use some idea how common this is.
Vít
But even if we apply some pattern matching, we hit the second problem: anyone who is doing mass spec file updates (either releng or some provenpackager), has now way to make use of this information. They are not going to contact hundreds of upstreams to submit a cleanup fix. The only realistic solution is what the guidelines say: it's up to the maintainer of the package to ferry any changes back "upstream".
(More generally: what would the point of keeping an "upstream" spec file be? Either the spec file is only used by one distro, in which case everyone is better off if it's kept in the downstream repo. Or it's used by multiple distros, in which case we either have an über-complex spec file with %if-spaghetti or a spec file that doesn't fit any distro well, and again, everyone would be better of if the spec file were downstream.)
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Dne 16. 11. 20 v 11:04 Vít Ondruch napsal(a):
I should not propose this, because I agree with the points bellow. But if we should have it, then:
Provides: upstream-spec(https://some.url/to/upstream/package.spec)
would be machine readable and it would give use some idea how common this is.
Great idea.
I sum it up in: https://pagure.io/packaging-committee/pull-request/1030
On Mon, 2020-11-16 at 09:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
(More generally: what would the point of keeping an "upstream" spec file be?
One common reason is to integrate maintenance and testing with code maintenance and testing, particularly to include package builds in CI runs.
On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
On Mon, 2020-11-16 at 09:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
(More generally: what would the point of keeping an "upstream" spec file be?
One common reason is to integrate maintenance and testing with code maintenance and testing, particularly to include package builds in CI runs.
That argument does sound somewhat reasonable, but I don't think it actually holds much water.
Essentially, packages which do CI are packages which use modern build systems. And with the modern build systems the spec file doesn't need to be tweaked after each version bump. If a "modern" package needs the spec file to be constantly adjusted just to build than something is very wrong.
I expect that the great majority of projects that do CI are just fine with using the "downstream" spec file, which can be easily pulled in from dist-git for the build. Doing this also has the obvious advantage that you can do CI on more than one downstream platform, using different spec files or debian control files or whatever arch has, as appropriate, without polluting the upstream repo with a dozen of downstream-specific build instructions.
Buuuut, even if it turns out that it's easier to keep the spec file in upstream, the upstream can have copy of the spec file and that spec file can diverge from the Fedora version. All that needs to happen is that the changes are periodically synchronized (e.g. right before the version bump in Fedora).
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
On Mon, 2020-11-16 at 09:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
(More generally: what would the point of keeping an "upstream" spec file be?
One common reason is to integrate maintenance and testing with code maintenance and testing, particularly to include package builds in CI runs.
That argument does sound somewhat reasonable, but I don't think it actually holds much water.
Essentially, packages which do CI are packages which use modern build systems. And with the modern build systems the spec file doesn't need to be tweaked after each version bump. If a "modern" package needs the spec file to be constantly adjusted just to build than something is very wrong.
I expect that the great majority of projects that do CI are just fine with using the "downstream" spec file, which can be easily pulled in from dist-git for the build. Doing this also has the obvious advantage that you can do CI on more than one downstream platform, using different spec files or debian control files or whatever arch has, as appropriate, without polluting the upstream repo with a dozen of downstream-specific build instructions.
Buuuut, even if it turns out that it's easier to keep the spec file in upstream, the upstream can have copy of the spec file and that spec file can diverge from the Fedora version. All that needs to happen is that the changes are periodically synchronized (e.g. right before the version bump in Fedora).
What you're missing with your "modern" build system argument is that the spec doesn't have to "constantly" be updated, but it is often ahead of downstream due to new files and dependencies.
I can't speak for all maintainers but I do exactly what you propose: re-sync before each downstream package release. Differences are purposely kept to a minimum for this reason, so that diffs are easy to understand to limit mistakes.
My project uses an upstream spec file for CI exactly as Adam describes.
rob
On Mon, Nov 16, 2020 at 03:31:08PM -0500, Rob Crittenden wrote:
Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
On Mon, 2020-11-16 at 09:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
(More generally: what would the point of keeping an "upstream" spec file be?
One common reason is to integrate maintenance and testing with code maintenance and testing, particularly to include package builds in CI runs.
That argument does sound somewhat reasonable, but I don't think it actually holds much water.
Essentially, packages which do CI are packages which use modern build systems. And with the modern build systems the spec file doesn't need to be tweaked after each version bump. If a "modern" package needs the spec file to be constantly adjusted just to build than something is very wrong.
I expect that the great majority of projects that do CI are just fine with using the "downstream" spec file, which can be easily pulled in from dist-git for the build. Doing this also has the obvious advantage that you can do CI on more than one downstream platform, using different spec files or debian control files or whatever arch has, as appropriate, without polluting the upstream repo with a dozen of downstream-specific build instructions.
Buuuut, even if it turns out that it's easier to keep the spec file in upstream, the upstream can have copy of the spec file and that spec file can diverge from the Fedora version. All that needs to happen is that the changes are periodically synchronized (e.g. right before the version bump in Fedora).
What you're missing with your "modern" build system argument is that the spec doesn't have to "constantly" be updated, but it is often ahead of downstream due to new files and dependencies.
For rust, python, go, ... we're moving towards a system where build deps are expressed in package metadata. We're not there fully, but that's clearly the direction with %generate_buildrequires.
For %files, most of the time we don't list most individual files either. Many packages list maybe a binary or two and the top-level package data directory. %license and %docs with relative paths takes care of the rest.
I can't speak for all maintainers but I do exactly what you propose: re-sync before each downstream package release. Differences are purposely kept to a minimum for this reason, so that diffs are easy to understand to limit mistakes.
My project uses an upstream spec file for CI exactly as Adam describes.
OK, but than all's fine, no? You sync the changes, and the downstream spec file is still canonical, as far as other Fedora maintainers are concerned.
I have no beef with using a spec file in the upstream repo for CI. I would do things differently myself, but that doesn't really matter. I'm only trying to push back against complaints about changes pushed to dist-git. The ability to have a canonical source for the spec file is crucial. And it's also crucial that this file is read-write, so that automated changes can be done across the distro.
Zbyszek
On Mon, 2020-11-16 at 22:07 +0000, Zbigniew Jędrzejewski-Szmek wrote:
I have no beef with using a spec file in the upstream repo for CI. I would do things differently myself, but that doesn't really matter. I'm only trying to push back against complaints about changes pushed to dist-git. The ability to have a canonical source for the spec file is crucial. And it's also crucial that this file is read-write, so that automated changes can be done across the distro.
Yeah, this is a better description of my position too. When I said I wished projects wouldn't consider upstream spec files canonical, I meant approximately this - the case I really dislike is when you touch a spec file downstream and then get a complaint that you shouldn't have done that, you should have sent a PR to some upstream repo instead. Bonus annoyance points when the distro ("downstream") spec does not reference the "upstream" spec at all so you could not possibly have known it existed at all.
Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a):
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
Nope. This section describes what is the primary (canonical) location for **Fedora** and that it is maintainer responsibilty to forward-port chenges from dist-git to upstream. When upstream of spec file exist. But the section does not mention how to indicate that the upstream of SPEC file exists and that other maintainers MAY send PR to that upstream if it is not urgent.
On 11/16/20 10:23 AM, Miroslav Suchý wrote:
Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a):
This is actually a good idea. I have lots of such spec files.
Is it a good idea to document this in Packaging Guidelines?
It is already in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
Nope. This section describes what is the primary (canonical) location for **Fedora** and that it is maintainer responsibilty to forward-port chenges from dist-git to upstream. When upstream of spec file exist. But the section does not mention how to indicate that the upstream of SPEC file exists and that other maintainers MAY send PR to that upstream if it is not urgent.
If it is not urgent, provnpackagers should not go and make packaging changes without talking to the maintainer first.
Am 16.11.20 um 10:28 schrieb Miro Hrončok:
If it is not urgent, provnpackagers should not go and make packaging changes without talking to the maintainer first.
+1
I think the main idea is that we try not to create artificial "hierarchies". Especially for a volunteer maintainer who maintains a few packages there might be a pretty strong emotional attachment to his packages which try to keep up to the highest packaging standards. If some provenpackager just goes into "his" package and seems to play by a different set of rules this can be pretty demotivating.
Felix
On 16.11.2020 11:33, Felix Schwarz wrote:
I think the main idea is that we try not to create artificial "hierarchies". Especially for a volunteer maintainer who maintains a few packages there might be a pretty strong emotional attachment to his packages which try to keep up to the highest packaging standards. If some provenpackager just goes into "his" package and seems to play by a different set of rules this can be pretty demotivating.
The main upstream for Fedora packages is the Fedora Package Sources. If the package need to be fixed, it must be fixed.
If the maintainer wants to maintain a separate external copy, they should manually backport changes made on the Fedora side.
IMO, proven packagers are doing the right thing.
Am 16.11.20 um 13:16 schrieb Vitaly Zaitsev via devel:
The main upstream for Fedora packages is the Fedora Package Sources. If the package need to be fixed, it must be fixed.
I agree with you here. The only point (though important imho) I want to make is that provenpackagers should not "circumvent" the package maintainer by default - even though I can imagine it is way faster just to push your change.
The main idea is that "everyone plays by the same rules" except for some special situations: - pre-announced mass changes - urgent fixes and maintainer does not react immediately
Felix
On 16.11.2020 13:35, Felix Schwarz wrote:
The only point (though important imho) I want to make is that provenpackagers should not "circumvent" the package maintainer by default - even though I can imagine it is way faster just to push your change.
Most of casual packagers simply ignore all pull requests and don't even check their mail. It is much more easier to fix the package manually than waiting 2-3 weeks for a response.
Am 16.11.20 um 14:03 schrieb Vitaly Zaitsev via devel:
Most of casual packagers simply ignore all pull requests and don't even check their mail. It is much more easier to fix the package manually than waiting 2-3 weeks for a response.
I think this is the root cause and a real problem (I complained about this myself several few times on this list). However I argue it is wrong starting to shortcut existing rules as this causes additional fallout for responsive maintainers who might feel disenfranchised.
Instead we should start thinking about ways to actually fix the root cause problem (and also how to integrate Fedora packaging much better with actual users, hopefully "converting" some users into packagers).
Felix
On 17.11.2020 09:46, Felix Schwarz wrote:
I think this is the root cause and a real problem (I complained about this myself several few times on this list).
Yes, ofc. I've submitted multiple PRs. Some of them haven't been merged. Later I got these packages through the Non-responsive maintainer procedure, manually merged the PRs and pushed to updates.
Instead we should start thinking about ways to actually fix the root cause problem (and also how to integrate Fedora packaging much better with actual users, hopefully "converting" some users into packagers).
I think it will be very difficult. Many maintainers simply don't have enough free time and their packages haven't been updated for ages. They also don't check email and never accept pull requests.
On Tue, Nov 17, 2020 at 12:43 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
On 17.11.2020 09:46, Felix Schwarz wrote:
I think this is the root cause and a real problem (I complained about this myself several few times on this list).
Yes, ofc. I've submitted multiple PRs. Some of them haven't been merged. Later I got these packages through the Non-responsive maintainer procedure, manually merged the PRs and pushed to updates.
Instead we should start thinking about ways to actually fix the root
cause problem (and also how to integrate Fedora packaging much better with actual users, hopefully "converting" some users into packagers).
I think it will be very difficult. Many maintainers simply don't have enough free time and their packages haven't been updated for ages. They also don't check email and never accept pull requests.
Radical and likely overkill idea...
Require CLAs be renewed annually. If they don't respond within a certain amount of time, the non-responsive maintainer process is automatically initiated (or another process/workflow that doesn't yet exist).
Thanks, Richard
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 16.11.2020 13:35, Felix Schwarz wrote:
The only point (though important imho) I want to make is that provenpackagers should not "circumvent" the package maintainer by default - even though I can imagine it is way faster just to push your change.
Most of casual packagers simply ignore all pull requests and don't even check their mail. It is much more easier to fix the package manually than waiting 2-3 weeks for a response.
Just because it's easier not to follow expected process doesn't mean they shouldn't.
If waiting too long is a problem, set a timeout - send a PR, if it's not merged in two weeks then provenpackager it in.
And if your change requires touching enough packages that this is untenable, I urge you to seriously rethink whether it's worth doing. (Spec file cleanups generally aren't, for instance.)
Thanks, --Robbie
On 17.11.2020 18:45, Robbie Harwood wrote:
Just because it's easier not to follow expected process doesn't mean they shouldn't.
Patching packages by proven packages is a completely normal workflow.
If waiting too long is a problem, set a timeout - send a PR, if it's not merged in two weeks then provenpackager it in.
Waiting for 2 weeks is too much, IMO.
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 17.11.2020 18:45, Robbie Harwood wrote:
Just because it's easier not to follow expected process doesn't mean they shouldn't.
Patching packages by proven packages is a completely normal workflow.
Something being normal doesn't mean it's good.
If waiting too long is a problem, set a timeout - send a PR, if it's not merged in two weeks then provenpackager it in.
Waiting for 2 weeks is too much, IMO.
Consider making less urgent changes, then. Provenpackager policy says that you should check with maintainers before applying patches.
Thanks, --Robbie