Dealing with the "my packages" problem

[David Airlie]

----- 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.

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.

Dave.