Dealing with the "my packages" problem

[Tomas Mraz]

On Čt, 2015-11-19 at 11:06 +0100, Martin Kolman wrote:
> On Wed, 2015-11-18 at 16:39 -0500, 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.
> 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

Yes, this would be almost perfect. If we can get such staging branches
to be automatically merged or merge canceled by the package owner to
work. It also needs a little cultural change but it should not be a
drastic change. Of course this should not encourage provenpackagers to
hastily produce incorrect changes and just depending on the review of
the owner.

We could also have a branch for regular packagers not provenpackagers
working in similar way but it would not be merged automatically but only
when the owner explicitly say so. You can probably already use private
branches for that but it is missing some automation and official
workflow definition.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)