Dealing with the "my packages" problem

[Rob Crittenden]

David Airlie wrote:
> 
> 
> ----- Original Message -----
>> From: "Brian C. Lane" <bcl at redhat.com>
>> To: devel at 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