On Mon, Oct 21, 2019 at 10:37 AM Piotr Karbowski <slashbe...@gentoo.org> wrote:
> Hi,
> I'd like to bring the topic of defining default policy to do changes to
> packages within ::gentoo that one does not maintain.
> This topic goes back from time to time on #gentoo-dev, and as I was
> told, it was originally sent to gentoo-dev mailing list by robbat2 (I
> failed to find this in archive, so if anyone have copy of it, please share).
> Current policy is to never touch ebuild that one did not claim as
> maintainer unless maintainer of said package allowed you to do so.
> This is a bit unhealthy, especially when some developers that maintain
> packages are out of reach, or the patches to update ebuild just rot on
> the bugzilla and are not taken in by maintainers.
> What I'd like to end with would be to set a policy that allows any
> developer with write access to ebuilds tree do changes that are small in
> scope, like a minor bug fixes, adding missing flags, version bumps,
> anything, that does not require complete overhaul of ebuild, with the
> option to set in metadata.xml that policy for specified package is to
> deny anyone but maintainers from doing changes.
> The packages that would require a flag to prohibit non-maintainers from
> doing changes would of course be those of toolchain, or other big in
> user base packages that are in very good shape, as in gnome packages,

GNOME is not in good shape.

> kde packages, X11 packages and so on.

These are in good shape.

> Of course, the policy would also define, that if there are any bug
> introduced by changes that non-maintainer made, it's responsibility of
> those who did the change in first place to fix it and clean any mess
> that it has created.
> I personally am fine with others doing changes to packages I own, as
> long as they won't break anything and I do know from the discussion on
> #gentoo-dev, that there are others who have similar opinion about it.
> Those who feel territorial and those who believe only maintainers should
> maintain specified packages can just set the flag in metadata.xml and
> continue with the current state of things for their packages.
> The reason why I would like to get default policy to allow-all is that I
> do not believe most of developers would want to go around all the
> packages they own and set it manually to allow others doing changes even
> if they're fine with others touching those packages.
> What do you think folks?

I typically operate this way:

If the package maintainer is active (on IRC, mailing lists, bugzilla)
I file a bug. If no response after a week or two, depending on the
importance of the change I commit it myself.

If the package is not actively maintained (maintainer-needed@ or the
maintainer has not touched the package in a long time while there are
open bugs without response, etc) and the change is trivial (missing
dependency, simple version bump for non-critical package, etc), then
I'll just commit it directly.

If the package is not actively maintained and the change is not
trivial, I file a bug and try to get the maintainer to review. If they
don't respond, I try to get others that may be interested to review
and then commit after 2 weeks.

For tree-wide stuff (package rename, removing amd64-fbsd keywords,
$Header: ...$, etc) I think a mailing list post announcing what you're
doing is a good idea. Wait a couple days for feedback and then do it.
No need to get an ack from individual maintainers.

I feel like these are pretty reasonable guidelines and have rarely
gotten me yelled at. I know that a lot of the details of my personal
behavior are subjective, but maybe that's good enough? Not sure. We
seem to always have some disagreeable person force us to codify common

Am I missing any cases? The only thing I can think of is maintainers
that are so territorial that try to prevent others from committing to
their packages and also are not responsive to bug reports. Fortunately
that is uncommon, but unfortunately it does still happen today. I
don't really know how to solve that, but /that/ seems like the only
real problem case to me.

Reply via email to