Dealing with the "my packages" problem

Haïkel hguemar at fedoraproject.org
Wed Nov 18 11:23:44 UTC 2015


2015-11-18 1:08 GMT+01:00 Jason L Tibbitts III <tibbs at math.uh.edu>:
> tl; dr: I have submitted the following RFE for pkgdb:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> Please add comments there if you have any.
>
> I know I'm not the only provenpackager to have applied a bugfix to
> someone's package only to be yelled at it for it.  Some maintainers are
> more prickly about having others touch the packages they maintain for
> the community than others, and unfortunately there's currently just no
> way to know whether you'll be thanked or flamed for helping out with a
> package.
>
> 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
>
> This would be purely advisory, with hopefully reasonable defaults.  I
> believe it has the potential to eliminate quite a bit of friction that
> provenpackagers must handle, as well as eliminate the hesitation some of
> us feel for fear of being flamed.
>
>  - J<

As a provenpackager, I prefer to send an heads up and briefly explain
(for non-trivial change) the reason. This lessen the friction a lot.

As a comaintainer, I've had issues with non-trivial changes and some
buggy updates (e.g. provenpackager pushing latest release though it's
known upstream to be broken).
Issues that could be avoided with minimal communications, I wish we
had an actual reviewing system that creates this communication and
lower the threshold to contributing at the same time.

Though I prefer review boards like gerrit or ReviewBoard, even a
simple Pull Requests based reviewing system as in Pague would be
welcome.

Regards,
H.


More information about the devel mailing list