On 01/28/2018 10:47 AM, Alec Warner wrote: > > > On Sun, Jan 28, 2018 at 1:09 PM, Zac Medico <zmed...@gentoo.org > <mailto:zmed...@gentoo.org>> wrote: > > On 01/28/2018 09:35 AM, Alec Warner wrote: > > > > > > On Sun, Jan 28, 2018 at 9:51 AM, Zac Medico <zmed...@gentoo.org > <mailto:zmed...@gentoo.org> > > <mailto:zmed...@gentoo.org <mailto:zmed...@gentoo.org>>> wrote: > > > > The --dynamic-deps=n default causes confusion for users that are > > accustomed to dynamic deps, therefore add a --changed-deps-report > > option that is enabled by default (if --usepkgonly is not > enabled). > > > > The --quiet option will suppress the report if none of the > packages > > having changed dependencies are in the dependency graph, since > they > > are harmless in that case. If any of these packages *are* in the > > dependency graph, then --quiet suppresses the big NOTE section of > > the report, but the HINT section is still displayed since it might > > help users resolve problems that are solved by --changed-deps. > > > > Example output is as follows: > > > > !!! Detected ebuild dependency change(s) without revision bump: > > > > net-misc/openssh-7.5_p1-r3::gentoo > > sys-fs/udisks-2.7.5::gentoo > > > > NOTE: For the ebuild(s) listed above, a new revision may be > > warranted if there > > has been a dependency change with significant consequences. > > Refer to the > > following page of the Gentoo Development Guide for > examples of > > circumstances that may qualify: > > > > > > > > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ > <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/> > > > <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/ > <https://devmanual.gentoo.org/general-concepts/ebuild-revisions/>> > > > > > If circumstances qualify, please report a bug which > specifies > > the current > > version of the ebuild listed above. Changes to ebuilds from > > the 'gentoo' > > repository (ending with '::gentoo') can be browsed in > GitWeb: > > > > https://gitweb.gentoo.org/repo/gentoo.git/ > <https://gitweb.gentoo.org/repo/gentoo.git/> > > <https://gitweb.gentoo.org/repo/gentoo.git/ > <https://gitweb.gentoo.org/repo/gentoo.git/>> > > > > Use Gentoo's Bugzilla to report bugs only for the 'gentoo' > > repository: > > > > https://bugs.gentoo.org/ > > > > In order to suppress reports about dependency changes, add > > --changed-deps-report=n to the EMERGE_DEFAULT_OPTS > variable in > > '/etc/portage/make.conf'. > > > > HINT: In order to avoid problems involving changed > dependencies, use the > > --changed-deps option to automatically trigger rebuilds when > > changed > > dependencies are detected. Refer to the emerge man page > for more > > information about this option. > > > > Bug: https://bugs.gentoo.org/645780 > > > > > > I can't really support sending this large report to users. > > > > 1) Its fairly common practice today. > > 2) All users will get the report. > > 3) A subset of them will file bugs about the report. > > 4) Devs make a decision about revbumping vs not; there doesn't seem to > > be a way for devs to say "no this change is intentional, stop nagging > > users." > > I think in practice we need to revbump for most changes. If the changes > weren't worth propagating, then we wouldn't make them. > > > Ultimately I'm unsure what we are trying to accomplish here. Do we think > > Devs are doing 4 on accident? > > It doesn't matter whether it's intentional or an accident. The problem > is that users need to learn to react appropriately, and I think > --change-deps-report is probably the most efficient way to train them. > > > I guess I'm less convinced users can / should do it. > > Like they have to read the ebuild-revisions guide in the devmanual and > decide if the revbump is required or not? > Do we think users are able to do this?
Maybe some. The worst case is that they file a bug and the developer gets to see a useful message in the bug report. I don't expect this case to be the norm, because I expect that developers usually do the right thing given the necessary reinforcement. > Should we consider only showing reports to developers (e.g. putting it > behind a 'dev' FEATURE?) What are the users supposed to do if they have dependency calculation failure and they don't know about the --changed-deps option? Why not instantly notified them that the --changed-deps option is available to solve their problems? Again, I don't expect this case to be the norm. It's a safety net. > > If so, why can't we give them tools to find it ahead of time (repoman > > et. al.) or tools to find it post-commit (tinderbox or similar; but > > these are single-sourced reports.) > > Sure that can be done, but it will take some work. Honestly I think the > devs can get it right without all that, they just need some > reinforcement that has been absent up until now. > > Meanwhile, users need to be trained to cope with whatever comes > their way. > > > I also feel like we are pushing action onto users here. If we agree with > > the premise that this is a bug (and devs should always bump) then we > > don't need users to take any action; > > I really do think that the devs can learn to get it right with a little > reinforcement. > > > we could build automation that sends these 'reports'. Its not like the > > user is going to add anything interesting to the report. Making them do > > it by hand just introduces transcription errors in filing. We just need > > to get their permission to file the reports automatically when portage > > finds them. > > The thing is, we let commits flow directly from git to rsync. Good luck > with finding volunteers to be the gatekeepers for this. > > > I'm not sure I follow on this part. > > Today we let commits flow from git to rsync. This patch proposes that > emerge detect when deps of installed ebuilds change w/o a revbump. > These reports encourage *users* to take an action (file a bug.) > > I'm suggesting that we automate that action. > > "here is a report for x,y,z, file a bug? (Y/n)" > > And users hit Y and we file a bug report with a template and all the > required fields filled in (because emerge has them.) > > I'm not proposing a 'gatekeeper'. Okay, so how do we train users to deal with the fallout, given that there's no gate? -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
