1 |
On 11/16/19 4:41 PM, Michał Górny wrote: |
2 |
> |
3 |
> More precisely, this is in context of dependency corrections. There is |
4 |
> no need to go through stabilization to restrict too broad dependency |
5 |
> specifications, while stable users hit the issue for the next two |
6 |
> months. |
7 |
> |
8 |
|
9 |
The word "dependency" doesn't appear on that page before the line that I |
10 |
have a problem with. |
11 |
|
12 |
I'm not arguing against common sense: if you need to fix something |
13 |
that's completely broken in a stable ebuild and if that fix requires a |
14 |
new revision, then do a new (straight to stable) revision. However, |
15 |
that's a rare situation, and the bullet point doesn't make it clear that |
16 |
it's referring to a specific rare situation that should be ignored 99% |
17 |
of the time in favor of the first bullet point. |
18 |
|
19 |
To make matters worse, the fact that you can push commits |
20 |
straight-to-stable to fix a bad issue in the stable tree is completely |
21 |
independent of whether or not you make a new revision. You could push an |
22 |
entirely new version with the same goal. So the fact that the exception |
23 |
to the rule appears as a bullet point on the "ebuild revisions" page |
24 |
only sows further confusion. |
25 |
|
26 |
When people pull up that page, that want a simple heuristic to follow, |
27 |
not a legal document that they have to decode for half an hour before |
28 |
they can fix a bug. |