7:02 a.m.
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
7:03 a.m.
On Mon, Nov 9, 2020 at 8:03 AM Honggang LI <honli(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
7:23 a.m.
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(a)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.
7:39 a.m.
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(a)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/55352ca3c535f31dfce9ab7779...
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
8:50 a.m.
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(a)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/55352ca3c535f31dfce9ab7779...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b
Author: Peter Robinson <pbrobinson(a)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
9:14 a.m.
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(a)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/55352ca3c535f31dfce9ab7779...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b
Author: Peter Robinson <pbrobinson(a)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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:22 a.m.
On Mon, Nov 9, 2020 at 3:15 PM Tom Hughes via devel
<devel(a)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.
9:17 a.m.
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(a)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/55352ca3c535f31dfce9ab7779...
commit 59a8e2e0d0ddba785fc79c4731e0b8685893458b
Author: Peter Robinson <pbrobinson(a)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_maintena...
Also minimizing package dependency chains possibly by splitting less
common functionality into subpackage welcomed change.
Vít
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
9:23 a.m.
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/59a8e2e0d0ddba785fc79c4731...
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).
9:17 a.m.
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
9:31 a.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:47 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:22 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:06 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
2:09 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý <msuchy(a)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_maintena...
> 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
>
3:22 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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(a)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_maintena...
"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
4:04 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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(a)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_maintena...
"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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
8:40 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
11:01 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:09 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
2:31 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
4:07 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
5:44 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:23 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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_maintena...
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.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
3:28 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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_maintena...
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:33 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
6:16 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:35 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
7:03 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:46 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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
12:43 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:01 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
On Tue, Nov 17, 2020 at 12:43 PM Vitaly Zaitsev via devel <
devel(a)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
11:45 a.m.
New subject: Upstream SPEC files - was: Re: patch applied without package maintainers' approve
Vitaly Zaitsev via devel <devel(a)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
12:34 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package
maintainers' approve
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:58 p.m.
New subject: Upstream SPEC files - was: Re: patch applied without package maintainers' approve
Vitaly Zaitsev via devel <devel(a)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
1264
days inactive
1273
days old
34 comments
18 participants
participants (18)
-
Adam Williamson -
Chuck Anderson -
Dominik 'Rathann' Mierzejewski -
Elliott Sales de Andrade -
Felix Schwarz -
Gary Buhrmaster -
Honggang LI -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Peter Robinson -
Richard Shaw -
Rob Crittenden -
Robbie Harwood -
Tom Hughes -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek