On Mon, 2018-12-17 at 05:12 +0000, M. J. Everitt wrote: > On 15/12/18 08:55, Michał Górny wrote: > > On Sat, 2018-12-15 at 02:25 +0000, M. J. Everitt wrote: > > > This patchset aims to fix potential ambiguity and confusion between older > > > PORT_LOG* variables, > > > and more recent PORTAGE_* variables - often leading to mysteriously > > > lacking logging due to > > > incorrect variable names. Documented in Bug 668538; with thanks to Zac > > > for diagnosis, and > > > solution assistance! > > > > > > > Does 'often' actually affect more than one person? Do you have any > > evidence to support this? > > > > Given that a lot of Portage variables don't have any prefix or sane > > names, I dare say this one doesn't especially stand out. > > > > Just a thought, but how about you apply your skill and wisdom to reviewing > the patches, instead of wasting it on writing snide replies? > Quite radical I know, but whadda ya think?!
You didn't answer my question. However, given the level of aggression in your reply, I'm going to presume I've caught you on a blatant lie and that this problem affects exactly one person, yourself, and you are making an unnecessary change to bend the world to your mistake. > As it happens, I was going for consistency here, as that often reflects > code quality, and you being a keen QA member, I'da thought perhaps you > might have spotted this! Are you? Do you have any evidence to support that? Because as far as I can see (and it's even quite visible in your patch), none of the variables in the group with 'PORT_LOGDIR' in it use 'PORTAGE_' prefix. So are you improving consistency in variable naming, or are you replacing one inconsistency with another? > Not only this, but as noted, unless you know the man pages for portage and > make.conf in order to recite them in your sleep, they are confusing for > users, as they do not necessarily follow an obvious pattern, and it wasn't > until I was attempting to debug something that I noticed that despite > believing I had the correct settings in my make.conf (set over a period of > YEARS) they were in fact completely useless, and it wasn't until I had to > spend time with somebody debugging WTF was happening, that this particular > issue even became apparent... I don't see how this is an argument for anything. You have to read the manual in order to know that such variable exists and what it does. Or, well, technically you don't since it's provided in make.conf.example already where you only need to uncomment it. Either way, the variable name is trivial. Even if you don't follow the usual pattern of uncommenting it from make.conf.example or copying from the manual, remembering it for the time needed to retype shoudln't be a problem. So, is this a solution to a real problem? Or is it merely a half- thought-out partial change that's going to require people to update their configuration for no long-term benefit? And then they will have to update it again when someone decides to take another variable for a spin. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
