On Wed, 2015-11-18 at 16:39 -0500, David Airlie wrote: > > ----- Original Message ----- > > From: "Brian C. Lane" <bcl@xxxxxxxxxx> > > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > > 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. I think it can be made to scale - at least in most cases. We could have a mechanism that stages the change and notifies the maintainer (eq. asks first automatically) and gives him the option to apply the change or cancel it & do it properly themselves. And if there is no reply from the maintainer, the change will be applied automatically after some time (24-48 hours ? could be configurable). I think this workflow would lessen the burden for both parties involved: * less work for proven packagers when "doing it right" (automatic asking, staging & auto apply) * maintainers get always notified automatically, can easily "ACK" trivial changes or cancel the change and do it properly if needed > > 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
