David Airlie wrote:
----- Original Message -----
> From: "Brian C. Lane" <bcl(a)redhat.com>
> To: devel(a)lists.fedoraproject.org
> Sent: Thursday, 19 November, 2015 7:05:57 AM
> Subject: Re: Dealing with the "my packages" problem
>
> On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote:
>> Matthew Miller wrote:
>>> On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote:
>>>> After some IRC discussion I've come to the following proposal: that
>>>> maintainers have some way to easily indicate how open they are to
>>>> external contributions. Basically this would take the form of a few
>>>> options in pkgdb where maintainers can indicate their willingness to
>>>> have provenpackagers carry out a few actions. Please read the github
>>>> ticket for details:
>>>>
https://github.com/fedora-infra/pkgdb2/issues/274
>>>
>>> What if we made the options be about _the package_ rather than about
>>> the maintainer's prickliness? Rather than "Please don't touch
my
>>> package" (I know that's not your wording; added for emphasis) make
it
>>> "This package has unusual complications; please coordinate any changes
>>> with the package maintainers."
>>>
>>> Well, except, less wordy. :)
>>>
>>> And, in thinking about it, I don't think we should encourage the
>>> option of "Don't even ask". If there really _is_ something
that's a big
>>> deal, the package maintainer can always say no when asked.
>>>
>>
>> As one of the complainers about current policy, here are my thoughts.
>>
>> I appreciate tibbs bringing up the discussion. I'd vote for a default
>> stance of "Ask first."
>
> I don't think we need a technical solution, we just need the people who
> feel the need to modify packages they aren't normally involved with to
> ask first. It doesn't matter how simple or complicated the change is,
> just be polite.
But that doesn't scale.
And scaling is important. We aren't developing a set of 4000s silos here,
we are meant to be developing a coherent operating system.
I have no insight into how many packages provenpackers are tweaking. I
guess I'd hope that the number would be low because of responsible
package <insert favorite synonym for maintainer>. I assume the number of
changes is << 4000.
You don't stuff, get over it, maintain it as best you can, if
someone else
screws it up, git revert and move on. If someone persistently screws things
up then we should deal with *that* problem. I don't think we have anyone
actively trying to screw up Fedora, so in theory we are all on the same team
and pulling in the same direction. So maybe if we started with an attitude
that they are have a good reason for touching the package, and worked with
that instead of defaulting to silos it would help a lot more.
That may be true but hopefully in most cases the maintainer or
co-maintainer knows a bit more about the package than some random
provenpackager. Having to revert changes is non-zero work.
I also wonder if I revert a provenpackager change, is that the end of
it? Who is the arbiter in this case if not?
rob