19.11.2015 14:35, 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@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
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.
Something like gitlab for our packages?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
