1 |
On Sun, Jan 28, 2018 at 1:09 PM, Zac Medico <zmedico@g.o> wrote: |
2 |
|
3 |
> On 01/28/2018 09:35 AM, Alec Warner wrote: |
4 |
> > |
5 |
> > |
6 |
> > On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmedico@g.o |
7 |
> > <mailto:zmedico@g.o>> wrote: |
8 |
> > |
9 |
> > The --dynamic-deps=n default causes confusion for users that are |
10 |
> > accustomed to dynamic deps, therefore add a --changed-deps-report |
11 |
> > option that is enabled by default (if --usepkgonly is not enabled). |
12 |
> > |
13 |
> > The --quiet option will suppress the report if none of the packages |
14 |
> > having changed dependencies are in the dependency graph, since they |
15 |
> > are harmless in that case. If any of these packages *are* in the |
16 |
> > dependency graph, then --quiet suppresses the big NOTE section of |
17 |
> > the report, but the HINT section is still displayed since it might |
18 |
> > help users resolve problems that are solved by --changed-deps. |
19 |
> > |
20 |
> > Example output is as follows: |
21 |
> > |
22 |
> > !!! Detected ebuild dependency change(s) without revision bump: |
23 |
> > |
24 |
> > net-misc/openssh-7.5_p1-r3::gentoo |
25 |
> > sys-fs/udisks-2.7.5::gentoo |
26 |
> > |
27 |
> > NOTE: For the ebuild(s) listed above, a new revision may be |
28 |
> > warranted if there |
29 |
> > has been a dependency change with significant consequences. |
30 |
> > Refer to the |
31 |
> > following page of the Gentoo Development Guide for examples of |
32 |
> > circumstances that may qualify: |
33 |
> |
34 |
> |
35 |
> > |
36 |
> > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ |
37 |
> > <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/> |
38 |
> |
39 |
> |
40 |
> > If circumstances qualify, please report a bug which specifies |
41 |
> > the current |
42 |
> > version of the ebuild listed above. Changes to ebuilds from |
43 |
> > the 'gentoo' |
44 |
> > repository (ending with '::gentoo') can be browsed in GitWeb: |
45 |
> > |
46 |
> > https://gitweb.gentoo.org/repo/gentoo.git/ |
47 |
> > <https://gitweb.gentoo.org/repo/gentoo.git/> |
48 |
> > |
49 |
> > Use Gentoo's Bugzilla to report bugs only for the 'gentoo' |
50 |
> > repository: |
51 |
> > |
52 |
> > https://bugs.gentoo.org/ |
53 |
> > |
54 |
> > In order to suppress reports about dependency changes, add |
55 |
> > --changed-deps-report=n to the EMERGE_DEFAULT_OPTS variable in |
56 |
> > '/etc/portage/make.conf'. |
57 |
> > |
58 |
> > HINT: In order to avoid problems involving changed dependencies, use |
59 |
> the |
60 |
> > --changed-deps option to automatically trigger rebuilds when |
61 |
> > changed |
62 |
> > dependencies are detected. Refer to the emerge man page for |
63 |
> more |
64 |
> > information about this option. |
65 |
> > |
66 |
> > Bug: https://bugs.gentoo.org/645780 |
67 |
> > |
68 |
> > |
69 |
> > I can't really support sending this large report to users. |
70 |
> > |
71 |
> > 1) Its fairly common practice today. |
72 |
> > 2) All users will get the report. |
73 |
> > 3) A subset of them will file bugs about the report. |
74 |
> > 4) Devs make a decision about revbumping vs not; there doesn't seem to |
75 |
> > be a way for devs to say "no this change is intentional, stop nagging |
76 |
> > users." |
77 |
> |
78 |
> I think in practice we need to revbump for most changes. If the changes |
79 |
> weren't worth propagating, then we wouldn't make them. |
80 |
> |
81 |
> > Ultimately I'm unsure what we are trying to accomplish here. Do we think |
82 |
> > Devs are doing 4 on accident? |
83 |
> |
84 |
> It doesn't matter whether it's intentional or an accident. The problem |
85 |
> is that users need to learn to react appropriately, and I think |
86 |
> --change-deps-report is probably the most efficient way to train them. |
87 |
> |
88 |
|
89 |
I guess I'm less convinced users can / should do it. |
90 |
|
91 |
Like they have to read the ebuild-revisions guide in the devmanual and |
92 |
decide if the revbump is required or not? |
93 |
Do we think users are able to do this? |
94 |
|
95 |
Should we consider only showing reports to developers (e.g. putting it |
96 |
behind a 'dev' FEATURE?) |
97 |
|
98 |
|
99 |
> |
100 |
> > If so, why can't we give them tools to find it ahead of time (repoman |
101 |
> > et. al.) or tools to find it post-commit (tinderbox or similar; but |
102 |
> > these are single-sourced reports.) |
103 |
> |
104 |
> Sure that can be done, but it will take some work. Honestly I think the |
105 |
> devs can get it right without all that, they just need some |
106 |
> reinforcement that has been absent up until now. |
107 |
> |
108 |
> Meanwhile, users need to be trained to cope with whatever comes their way. |
109 |
> |
110 |
> > I also feel like we are pushing action onto users here. If we agree with |
111 |
> > the premise that this is a bug (and devs should always bump) then we |
112 |
> > don't need users to take any action; |
113 |
> |
114 |
> I really do think that the devs can learn to get it right with a little |
115 |
> reinforcement. |
116 |
> |
117 |
> > we could build automation that sends these 'reports'. Its not like the |
118 |
> > user is going to add anything interesting to the report. Making them do |
119 |
> > it by hand just introduces transcription errors in filing. We just need |
120 |
> > to get their permission to file the reports automatically when portage |
121 |
> > finds them. |
122 |
> |
123 |
> The thing is, we let commits flow directly from git to rsync. Good luck |
124 |
> with finding volunteers to be the gatekeepers for this. |
125 |
> |
126 |
|
127 |
I'm not sure I follow on this part. |
128 |
|
129 |
Today we let commits flow from git to rsync. This patch proposes that |
130 |
emerge detect when deps of installed ebuilds change w/o a revbump. |
131 |
These reports encourage *users* to take an action (file a bug.) |
132 |
|
133 |
I'm suggesting that we automate that action. |
134 |
|
135 |
"here is a report for x,y,z, file a bug? (Y/n)" |
136 |
|
137 |
And users hit Y and we file a bug report with a template and all the |
138 |
required fields filled in (because emerge has them.) |
139 |
|
140 |
I'm not proposing a 'gatekeeper'. |
141 |
|
142 |
-A |
143 |
|
144 |
-- |
145 |
> Thanks, |
146 |
> Zac |
147 |
> |
148 |
> |