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 i
Vitaly Zaitsev via devel 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
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 mult
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
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 th
Vitaly Zaitsev via devel 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
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 compl
On Mon, 2020-11-16 at 22:07 +, 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.
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 +, Zbigniew Jędrzejewski-Szmek wrote:
> >>>
> >>> (More generally: what would the point of k
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 +, Zbigniew Jędrzejewski-Szmek wrote:
>>>
>>> (More generally: what would the point of keeping an "upstream" spec
>>> file be?
>>
>> One common reason is to integ
On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
> On Mon, 2020-11-16 at 09:22 +, 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
On Mon, 2020-11-16 at 09:22 +, 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 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 p
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 "circu
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 packa
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
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ý wrote:
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
If you're going to have this kind of "upstream" spec f
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/
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
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ý 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
On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý 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 tha
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 t
22 matches
Mail list logo