On Wed, Feb 3, 2016 at 2:19 PM, Michael Schwendt <mschwe...@gmail.com> wrote:
> On Wed, 3 Feb 2016 16:04:19 +0000, Jonathan Wakely wrote:
>
>> When a provenpackager is rebuilding *hundreds* of packages at once,
>> and trying to deal with maybe dozens of build failures, sending emails
>> to all the package owners and waiting to see if they respond promptly
>> is not an efficient way to get things fixed. Waiting for a reply adds
>> a lot of latency, and then you have to context-switch back to a
>> package you were dealing with a day or two ago. That's impractical
>> when you have a patch ready to go now and loads more packages to look
>> at.
>
> https://fedoraproject.org/wiki/Provenpackager_policy
>
>  | Provenpackagers should try to communicate with owners of a package in
>  | bugzilla, irc or email prior to making changes.
>
>  | They should be careful not to change other people's packages needlessly
>  | and try to do the minimal changes required to fix problems, as explained
>  | more in depth in the policy explaining who is allowed to modify which
>  | packages.
>  | -> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
>
> Even if says "should" two times, Jerry refers to "no prior contact" and
> a version upgrade to alpha level software. That doesn't sound like anything
> provenpackagers should do within arbitrary packages.
>
> I wonder whether a message at the top would have changed the provenpackager's
> mind?
>

Yes, as far as the guidelines state, provenpackager is not carte
blanche to do drive-by modifications of packages at will - there needs
to be communication, even if it seems inconvenient.  For that matter,
it's also not license to violate packaging guidelines by adding
patches without comments or upgrading versions outside of the stable
update guidelines, so I sympathize with Jerry's original mail in that
respect.

If you read 
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages,
there's even more suggestions for how to go about editing others'
packages, including:

"if you committed changes to another package wait some hours if
possible (normally 24 or 48) before you actually build the updated
package as long it is nothing serious that should be fixed quickly
(security problems, ...). That leaves some time for the maintainer to
wake up ;-) "

I'll also not that the above page seems not reflect at all the "Nobody
owns packages" mantra that Jerry is responding to, like where it says:

"Normally the maintainer that is listed as primary maintainer in the
PackageDB (formerly this was owners.list) of a package is the only one
who modifies the package or gives others permission (e.g. by accepting
them as co-maintainers) to commit and build changes for that package."

I'm not sure who maintains that page or if its an official guideline,
but it certainly outlines what my impresson of the best way to go
about changing things is.

Speaking for myself, I do all of my Fedora work in my free time
outside of $DAYJOB, so I do appreciate when others step in and help
out with issues in my packages.  It also means I'm not always able to
respond to bug reports or rawhide failures within a couple of days,
but I do try my best to get to things within a week or so.  That said,
I do have a life, and things occasionally fall off of my radar.
Keeping up with others' changes to my packages, especially if they're
not high caliber changes, just takes more time I could be spending on
other things.  It's a much better use of my time to respond to a bug
or email to the package-owner alias about forthcoming changes than to
try to reverse engineer changes after the fact.

In that vein, and to address the *hundreds* of packages at once issue,
a mass email to package owner aliases that says "i'm going to make X
huge change in a few days, these are the packages affected, I plan on
resolving fallout, let me know if you'd like to handle it instead" is
a good compromise that only extends the time it takes for you to do
your work by a reasonable notification period.  Similarly, status
updates like "This side tag will be merged on $DATE, please be ready
for fall-out" will help everyone else help you for big changes.

>> Sometimes a provenpackager will make a bad change, and that's
>> unfortunate, but it happens. Sometimes package owners make bad changes
>> too! :-)
>
> You're taking it too lightly. Somebody who performs version upgrades really
> needs to take care of a package and incoming problem reports as well.

Agreed.  "They did it too!" is not a strong defense.  I also object to
the following comment:

>> If I appear
>> to change things and walk away it's probably because I've moved on to
>> look at other packages that also need attention, not just a careless
>> hit & run. I would expect it's similar for others.

These things are not mutually exclusive. Other packagers can't tell
what you're up to if you don't communicate with them.

Rich
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Reply via email to