| 1 |
On 10/24/19 10:03 PM, Michael Everitt wrote: |
| 2 |
> |
| 3 |
> Forgive my lack of git-fu, but which commit did this? Can we name & shame |
| 4 |
> the author and committer publicly, and in front of QA, so that this kind of |
| 5 |
> violation is highlighted to all, and noted for future reference? |
| 6 |
> |
| 7 |
|
| 8 |
I left it out on purpose. This isn't a one-person problem, and my anger |
| 9 |
isn't only targeted at the last person who was unlucky enough to do it |
| 10 |
right before I snapped and wrote the email. |
| 11 |
|
| 12 |
This comes up on the -dev list several times a year. We've fought about |
| 13 |
ecosystems adding dependencies to stable packages via eclass USE flags. |
| 14 |
We fight about the revision policy in the devmanual. We've been fighting |
| 15 |
about dynamic dependencies in the package manager for 10+ years. The |
| 16 |
portage team basically quit once over this. A few years later we fought |
| 17 |
about it again and finally turned them off, but the commit got reverted |
| 18 |
when users complained that developers were constantly breaking things. |
| 19 |
That contributed to a fork of the package manager... |
| 20 |
|
| 21 |
Point is, it's not a new thing. And it's a huge waste of time for |
| 22 |
everyone involved. It's also simple to avoid. Just make a new revision |
| 23 |
when you change something. You shouldn't be changing stable ebuilds |
| 24 |
*anyway*, but if you're already going to violate that policy, it doesn't |
| 25 |
do any more harm to move it to -r1 in the process. |
Archives