| 1 |
On Mon, Oct 21, 2019 at 10:37 AM Piotr Karbowski <slashbeast@g.o> wrote: |
| 2 |
> |
| 3 |
> Hi, |
| 4 |
> |
| 5 |
> I'd like to bring the topic of defining default policy to do changes to |
| 6 |
> packages within ::gentoo that one does not maintain. |
| 7 |
> |
| 8 |
> This topic goes back from time to time on #gentoo-dev, and as I was |
| 9 |
> told, it was originally sent to gentoo-dev mailing list by robbat2 (I |
| 10 |
> failed to find this in archive, so if anyone have copy of it, please share). |
| 11 |
> |
| 12 |
> Current policy is to never touch ebuild that one did not claim as |
| 13 |
> maintainer unless maintainer of said package allowed you to do so. |
| 14 |
> |
| 15 |
> This is a bit unhealthy, especially when some developers that maintain |
| 16 |
> packages are out of reach, or the patches to update ebuild just rot on |
| 17 |
> the bugzilla and are not taken in by maintainers. |
| 18 |
> |
| 19 |
> What I'd like to end with would be to set a policy that allows any |
| 20 |
> developer with write access to ebuilds tree do changes that are small in |
| 21 |
> scope, like a minor bug fixes, adding missing flags, version bumps, |
| 22 |
> anything, that does not require complete overhaul of ebuild, with the |
| 23 |
> option to set in metadata.xml that policy for specified package is to |
| 24 |
> deny anyone but maintainers from doing changes. |
| 25 |
> |
| 26 |
> The packages that would require a flag to prohibit non-maintainers from |
| 27 |
> doing changes would of course be those of toolchain, or other big in |
| 28 |
> user base packages that are in very good shape, as in gnome packages, |
| 29 |
|
| 30 |
GNOME is not in good shape. |
| 31 |
|
| 32 |
> kde packages, X11 packages and so on. |
| 33 |
|
| 34 |
These are in good shape. |
| 35 |
|
| 36 |
> Of course, the policy would also define, that if there are any bug |
| 37 |
> introduced by changes that non-maintainer made, it's responsibility of |
| 38 |
> those who did the change in first place to fix it and clean any mess |
| 39 |
> that it has created. |
| 40 |
> |
| 41 |
> I personally am fine with others doing changes to packages I own, as |
| 42 |
> long as they won't break anything and I do know from the discussion on |
| 43 |
> #gentoo-dev, that there are others who have similar opinion about it. |
| 44 |
> |
| 45 |
> Those who feel territorial and those who believe only maintainers should |
| 46 |
> maintain specified packages can just set the flag in metadata.xml and |
| 47 |
> continue with the current state of things for their packages. |
| 48 |
> |
| 49 |
> The reason why I would like to get default policy to allow-all is that I |
| 50 |
> do not believe most of developers would want to go around all the |
| 51 |
> packages they own and set it manually to allow others doing changes even |
| 52 |
> if they're fine with others touching those packages. |
| 53 |
> |
| 54 |
> What do you think folks? |
| 55 |
|
| 56 |
I typically operate this way: |
| 57 |
|
| 58 |
If the package maintainer is active (on IRC, mailing lists, bugzilla) |
| 59 |
I file a bug. If no response after a week or two, depending on the |
| 60 |
importance of the change I commit it myself. |
| 61 |
|
| 62 |
If the package is not actively maintained (maintainer-needed@ or the |
| 63 |
maintainer has not touched the package in a long time while there are |
| 64 |
open bugs without response, etc) and the change is trivial (missing |
| 65 |
dependency, simple version bump for non-critical package, etc), then |
| 66 |
I'll just commit it directly. |
| 67 |
|
| 68 |
If the package is not actively maintained and the change is not |
| 69 |
trivial, I file a bug and try to get the maintainer to review. If they |
| 70 |
don't respond, I try to get others that may be interested to review |
| 71 |
and then commit after 2 weeks. |
| 72 |
|
| 73 |
For tree-wide stuff (package rename, removing amd64-fbsd keywords, |
| 74 |
$Header: ...$, etc) I think a mailing list post announcing what you're |
| 75 |
doing is a good idea. Wait a couple days for feedback and then do it. |
| 76 |
No need to get an ack from individual maintainers. |
| 77 |
|
| 78 |
I feel like these are pretty reasonable guidelines and have rarely |
| 79 |
gotten me yelled at. I know that a lot of the details of my personal |
| 80 |
behavior are subjective, but maybe that's good enough? Not sure. We |
| 81 |
seem to always have some disagreeable person force us to codify common |
| 82 |
sense. |
| 83 |
|
| 84 |
Am I missing any cases? The only thing I can think of is maintainers |
| 85 |
that are so territorial that try to prevent others from committing to |
| 86 |
their packages and also are not responsive to bug reports. Fortunately |
| 87 |
that is uncommon, but unfortunately it does still happen today. I |
| 88 |
don't really know how to solve that, but /that/ seems like the only |
| 89 |
real problem case to me. |
Archives