* Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
2019-10-21 17:37 [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers Piotr Karbowski
@ 2019-10-21 18:06 ` Matthew Thode
2019-10-22 0:36 ` Kent Fredric
2019-10-22 0:55 ` Matt Turner
2 siblings, 0 replies; 6+ messages in thread
From: Matthew Thode @ 2019-10-21 18:06 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]
On 19-10-21 19:37:28, Piotr Karbowski 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,
> kde packages, X11 packages and so on.
>
> 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?
>
> -- Piotr.
>
I like the idea of setting metadata.xml options so repoman can help
enforce things. Not sure if we talked about it earlier but it was an
option that popped up in the last couple of weeks in the -dev channel.
--
Matthew Thode (prometheanfire)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
2019-10-21 17:37 [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers Piotr Karbowski
2019-10-21 18:06 ` Matthew Thode
@ 2019-10-22 0:36 ` Kent Fredric
2019-10-22 0:58 ` Matt Turner
2019-10-22 0:55 ` Matt Turner
2 siblings, 1 reply; 6+ messages in thread
From: Kent Fredric @ 2019-10-22 0:36 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On Mon, 21 Oct 2019 19:37:28 +0200
Piotr Karbowski <slashbeast@gentoo.org> wrote:
> 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.
IME this is far from the norm and should not be used as the
justification here.
I would argue some *honest* attempt be made to contact the people
officially responsible for the package.
If they can't be contacted in a reasonable time frame, sure, by all
means.
But I cannot support a policy where it creates a conjecture of "I think
this patch doesn't matter, so I'll just do it".
Because in practice, no change, no matter how apparently insignificant,
is immune from the risk of creating a quality reduction.
And no change, is immune from potentially affecting the package
maintainers workflow. ( For example, if you drop in a sed, or a patch,
when the package uses a carefully curated tar-ball of patches which are
also carefully tested against upstream sources on travis or something,
by dropping the patch in unconsulted, you run the risk of pissing
somebody off by adding a patch in ways that by-passes and potentially
confounds these efforts. )
It really sucks having to review somebodies changes after-the-fact
where you discover the change long after it was done, because nobody
even tried to communicate.
Reasonable attempts should be made, _especially_ if there are multiple
maintainers for a package, or a project with multiple members.
If you don't have the patience to even wait _one_ day for a response,
maybe you shouldn't be doing opensource.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
2019-10-22 0:36 ` Kent Fredric
@ 2019-10-22 0:58 ` Matt Turner
2019-10-22 4:07 ` Kent Fredric
0 siblings, 1 reply; 6+ messages in thread
From: Matt Turner @ 2019-10-22 0:58 UTC (permalink / raw
To: gentoo development
On Mon, Oct 21, 2019 at 5:37 PM Kent Fredric <kentnl@gentoo.org> wrote:
>
> On Mon, 21 Oct 2019 19:37:28 +0200
> Piotr Karbowski <slashbeast@gentoo.org> wrote:
>
> > 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.
>
> IME this is far from the norm and should not be used as the
> justification here.
I think exceptional cases are the reason for many, many policies in
Gentoo. That probably doesn't surprise you.
> If you don't have the patience to even wait _one_ day for a response,
> maybe you shouldn't be doing opensource.
I'm not sure what this is in reference to so it seems to be a
non-sequitur, but I like the policy of at least waiting a day for
review of non-critical fixes. Phrased another way, let people in every
timezone have a chance.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
2019-10-22 0:58 ` Matt Turner
@ 2019-10-22 4:07 ` Kent Fredric
0 siblings, 0 replies; 6+ messages in thread
From: Kent Fredric @ 2019-10-22 4:07 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]
On Mon, 21 Oct 2019 17:58:51 -0700
Matt Turner <mattst88@gentoo.org> wrote:
> I'm not sure what this is in reference to so it seems to be a
> non-sequitur, but I like the policy of at least waiting a day for
> review of non-critical fixes. Phrased another way, let people in every
> timezone have a chance.
Its not aimed so much at the person writing this proposal, but more so,
something that has happened before and was annoying and I had to have
annoying conversations about why this was not-ok, where the agent in
question didn't attempt to reach out to any team member of a very
critical package before "just doing it".
The nature of the change *was* simple enough that had we seen it, we'd
have ACKed it easily.
But the need to get lucky and spot the commit in the history and review
it after-the-fact hoping the agent didn't break anything is where this
is "not-ok".
Yes, I hate to have to re-iterate in policy behaviour that I consider
to be a sensible reasonable default... but it turns out, not everyone
has that same sensibility.
I'm fine with a policy that allows for non-maintainer contributions,
just the stipulations of "try contact the maintainer, wait a reasonable
amount of time based on the overall combination of that packages
importance and the effective availability of people who maintain it to
even respond to a ping".
Because the fact is, non-maintainers have substantially less
understanding of the total net of complexities, both in portage and
outside of portage (by way of project specific tracking projects), and
they're less equipped to make a judgement call as to wether or not a
change that looks trivial, is trivial in the grand scheme of things.
( For instance, tweaking the package-keywords entries on bulk keyword
request I filed riles me up, because I need a lot of tooling to
maintain that stuff, and currently, other people tweaking stuff that is
outside their responsibilities messes with my ability to do this
effectively. And this isn't even visible 'in portage', its just more of
the same pattern of 'touching stuff that's not your responsibility to
touch without contacting the people whos responsibility it is' )
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
2019-10-21 17:37 [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers Piotr Karbowski
2019-10-21 18:06 ` Matthew Thode
2019-10-22 0:36 ` Kent Fredric
@ 2019-10-22 0:55 ` Matt Turner
2 siblings, 0 replies; 6+ messages in thread
From: Matt Turner @ 2019-10-22 0:55 UTC (permalink / raw
To: gentoo development
On Mon, Oct 21, 2019 at 10:37 AM Piotr Karbowski <slashbeast@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
sense.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread