On 07/14/2018 12:47 AM, Kevin Fenzi wrote:
On 07/12/2018 07:45 AM, Miro Hrončok wrote:
I second that. When we mass filled PRs with python2 related changes it
was always a Red Hat maintained software, where people were basically
telling us: "no, we won't accept your PR here, we maintain the spec
On 07/12/2018 10:24 AM, Ken Dreyer wrote:
> On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser wrote:
>> We have been telling people for a while now that they don't "own"
>> their packages. Making it easier for people to maintain their packages
>> outside of dist-git and (effectively) ignore changes fro
On 07/12/2018 07:45 AM, Miro Hrončok wrote:
> I second that. When we mass filled PRs with python2 related changes it
> was always a Red Hat maintained software, where people were basically
> telling us: "no, we won't accept your PR here, we maintain the specfile
> somewhere else". It was very unpl
On 07/11/2018 03:38 PM, Emmanuel Seyman wrote:
> * Kevin Fenzi [11/07/2018 12:47] :
>>
>> Barring that, I think we will just continue to have people make changes
>> and them get overwritten.
>
> Does this include changes that were made for security reasons (disabling
> a compile-time option, doing
> "MM" == Matthew Miller writes:
MM> Yeah, this argument seems pretty compelling to me. I think that if
MM> people want to maintain an outside spec file, they *must* also
MM> respect changes made to the primary one in dist-git.
I took a break from this discussion, but I did want to point out
On Thu, 12 Jul 2018, Miro Hrončok wrote:
> > > The guidelines currently say:
Are these Holy Writ, or just process, subject to amendment?
> > > I think this guideline is bad and counterproductive, since many
> > > packages clearly ignore it.
There is a principle:
Seek first to understan
On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser wrote:
> We have been telling people for a while now that they don't "own"
> their packages. Making it easier for people to maintain their packages
> outside of dist-git and (effectively) ignore changes from
> proven-packagers seems to take us in the op
On 12.7.2018 00:11, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:
The guidelines currently say:
https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity
"Fedora's git repository is the canonical location for Fedora sp
Simo Sorce wrote:
> Isn't tooling in our dist-git commit hooks or push hooks that simply
> reject commits that remove changelogs or re-add unwanted sections the
> way to go here ?
Removing changelog entries is necessary to bring diverged branches back into
sync. I always destroy the branch change
On Wed, 2018-07-11 at 12:16 -0400, Josh Boyer wrote:
> On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
> wrote:
> >
> > On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer > rg> wrote:
> > >
> > > On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III > > .uh.edu> wrote:
> > > >
> > > > > > > > > "JB" =
* Kevin Fenzi [11/07/2018 12:47] :
>
> Barring that, I think we will just continue to have people make changes
> and them get overwritten.
Does this include changes that were made for security reasons (disabling
a compile-time option, doing a dangerous chown/chmod call, ...)?
If so, I'm not very c
On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:
> The guidelines currently say:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity
>
> "Fedora's git repository is the canonical location for Fedora spec
> files. Maintainers MUST expect that other m
Ben Rosser wrote:
> Only if you consider packaging metadata to be part of "the code base".
> I guess that's the crux of the issue, some people want to treat it
> this way and others don't.
Packaging metadata has no business being part of the upstream code. Even for
code bases where I am both the
On Wed, Jul 11, 2018 at 3:42 PM, Josh Boyer wrote:
> I disagree. "Ownership" within Fedora is one aspect we've tried to
> address, but we're pretending that Fedora "owns" the code base which
> is a falsity. There are many more people involved and in this
> specific kind of situation, pretending
On Wed, Jul 11, 2018 at 2:13 PM Matthew Miller wrote:
>
> On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> > We have been telling people for a while now that they don't "own"
> > their packages. Making it easier for people to maintain their packages
> > outside of dist-git and (effect
On Wed, Jul 11, 2018 at 02:12:37PM -0400, Matthew Miller wrote:
> On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> > We have been telling people for a while now that they don't "own"
> > their packages. Making it easier for people to maintain their packages
> > outside of dist-git and
On Wed, Jul 11, 2018 at 1:40 PM Ben Rosser wrote:
>
> On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer
> wrote:
> > Because nobody is communicating with upstream and fixing it there. In
> > some cases it'll be met with a shrug (like changelogs). In many, it
> > might actually result in upstream ma
On 07/11/2018 10:39 AM, Ben Rosser wrote:
> On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer
> wrote:
>> Because nobody is communicating with upstream and fixing it there. In
>> some cases it'll be met with a shrug (like changelogs). In many, it
>> might actually result in upstream making a similar
On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> We have been telling people for a while now that they don't "own"
> their packages. Making it easier for people to maintain their packages
> outside of dist-git and (effectively) ignore changes from
> proven-packagers seems to take us in
On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer wrote:
> Because nobody is communicating with upstream and fixing it there. In
> some cases it'll be met with a shrug (like changelogs). In many, it
> might actually result in upstream making a similar fix.
What is "upstream", though? Some repository
On Wed, Jul 11, 2018 at 12:16:45PM -0400, Josh Boyer wrote:
>
> > maintain their specs wherever they want, but they should be prepared that
> > Fedora will change their specs and they should not overwrite such changes.
>
> I said that as well. What you're missing is the part where people
> tell
On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
wrote:
>
> On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer wrote:
>>
>> On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III
>> wrote:
>> >
>> > > "JB" == Josh Boyer writes:
>> >
>> > JB> That's impossible to enforce and unrealistic.
>> >
>> > I w
On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer
wrote:
> On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III
> wrote:
> >
> > > "JB" == Josh Boyer writes:
> >
> > JB> That's impossible to enforce and unrealistic.
> >
> > I will go as far as "it's somewhat difficult to enforce and idealistic",
On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III wrote:
>
> > "JB" == Josh Boyer writes:
>
> JB> That's impossible to enforce and unrealistic.
>
> I will go as far as "it's somewhat difficult to enforce and idealistic",
> but no further.
>
> JB> We can say that as much as we'd like, but
> "JB" == Josh Boyer writes:
JB> That's impossible to enforce and unrealistic.
I will go as far as "it's somewhat difficult to enforce and idealistic",
but no further.
JB> We can say that as much as we'd like, but there is nothing we can do
JB> to prevent people from syncing from elsewhere.
On Tue, Jul 10, 2018 at 8:27 PM Jason L Tibbitts III wrote:
>
> Unfortunately it seems that many of these packages have had the
> BuildRoot tags _added back in_ after previously having them removed. A
> number of the commits even delete existing changelog entries, a sure
> sign that someone is ju
Unfortunately it seems that many of these packages have had the
BuildRoot tags _added back in_ after previously having them removed. A
number of the commits even delete existing changelog entries, a sure
sign that someone is just copying the specfile from some outside source.
As a reminder, the F
On Tue, Jul 10, 2018 at 03:03:56PM -0500, Jason L Tibbitts III wrote:
> The usual lists are below. Feel free to fix your packages if you like;
> there should be no need to rebuild. I will wait a few days and then fix
> up the instances which remain.
Thanks! It'll be nice to see BuildRoot finally
The Packaging Guidelines indicate that BuildRoot: should not be used in
Fedora specfiles.
The BuildRoot: tag has not been required since RHEL6 and was also not
required in EPEL5 (due to some magic in epel-rpm-macros). It has not
been needed in any Fedora release since at least Fedora 12.
It has
29 matches
Mail list logo
