| 1 |
On Mon, 21 Oct 2019 19:37:28 +0200 |
| 2 |
Piotr Karbowski <slashbeast@g.o> wrote: |
| 3 |
|
| 4 |
> This is a bit unhealthy, especially when some developers that maintain |
| 5 |
> packages are out of reach, or the patches to update ebuild just rot on |
| 6 |
> the bugzilla and are not taken in by maintainers. |
| 7 |
|
| 8 |
IME this is far from the norm and should not be used as the |
| 9 |
justification here. |
| 10 |
|
| 11 |
I would argue some *honest* attempt be made to contact the people |
| 12 |
officially responsible for the package. |
| 13 |
|
| 14 |
If they can't be contacted in a reasonable time frame, sure, by all |
| 15 |
means. |
| 16 |
|
| 17 |
But I cannot support a policy where it creates a conjecture of "I think |
| 18 |
this patch doesn't matter, so I'll just do it". |
| 19 |
|
| 20 |
Because in practice, no change, no matter how apparently insignificant, |
| 21 |
is immune from the risk of creating a quality reduction. |
| 22 |
|
| 23 |
And no change, is immune from potentially affecting the package |
| 24 |
maintainers workflow. ( For example, if you drop in a sed, or a patch, |
| 25 |
when the package uses a carefully curated tar-ball of patches which are |
| 26 |
also carefully tested against upstream sources on travis or something, |
| 27 |
by dropping the patch in unconsulted, you run the risk of pissing |
| 28 |
somebody off by adding a patch in ways that by-passes and potentially |
| 29 |
confounds these efforts. ) |
| 30 |
|
| 31 |
It really sucks having to review somebodies changes after-the-fact |
| 32 |
where you discover the change long after it was done, because nobody |
| 33 |
even tried to communicate. |
| 34 |
|
| 35 |
Reasonable attempts should be made, _especially_ if there are multiple |
| 36 |
maintainers for a package, or a project with multiple members. |
| 37 |
|
| 38 |
If you don't have the patience to even wait _one_ day for a response, |
| 39 |
maybe you shouldn't be doing opensource. |
Archives