On Tue, 15 Nov 2016 13:03:43 +0100 Lukas Ocilka <[email protected]> wrote:
> On 15.11.2016 12:47, Josef Reidinger wrote: > > Hi, > > currently as I touch warning levels in proposal clients I get idea > > to a bit unify that levels to make it easier to use it, test it and > > also simplify handling code in proposal runner. > > > > What are current levels: > > > > notice: only one that is not in red color > > warning: just shown > > error: now ask user to continue even with it > > blocker: block clicking on Install/Update button > > fatal: beside blocking also stop evaluation other proposals > > Yes, we've discussed that five is just too much and too confusing > > > My suggestion is: > > > > drop notice level ( when passed, do not display it, just throw it > > away ) > > Then we should at least log it, exception might be too much though I am just saying that we do not display it. Logging it with deprecation warning make sense as for other dropped levels. > > > merge warning and error into one warning with current behavior of > > error > > Well, it's not an error, it's a warning as you can continue > > > merge blocker and fatal into one fatal with current behavior of > > fatal > > Here 'Error' would be better, but as we merge only 'Fatal' and > 'Blocker', then we can't switch to 'Error', so good choice. > > > current usage of levels in git checkout: > > > > notice: 0 > > --> nothing, nice > > > warning: 11 > > error: 3 > > --> warning (just 3 errors and you can skip them anyway) > > > blocker: 17 > > fatal: 5 > > --> blocking anyway > > > and when we talk about API of this call. I also do not like ability > > to allow only one warning with level. So e.g. if bootloader find two > > problems, then only one can be shown to user with only one level. > > > > So I also propose to introduce new key in description map like > > "warnings" that contain pairs of [level, msg] so more warnings can > > be given. > > I'm always a bit confused with "warnings" if these are actually > "messages", so why not "messages"? because API is actually `make_proposal` which returns hash with a lot of entries see https://github.com/yast/yast-yast2/blob/master/library/general/src/lib/installation/proposal_client.rb so simple messages will be very confusing as there is already preformated_proposal which holds info about proposal. Now it uses "warning" and "warning_level" for warning that happen during proposal. It have problem that only one can happen and it is variously workarounded, see for example packager - https://github.com/yast/yast-packager/blob/93d41b2891706e779bab9e921c5f8693eb2720f9/src/modules/Packages.rb#L464 where it increase level if it is not big enough and concating warning messages, which is not nice. and each module have to do it on its own. And also it is not just messages, but message with its severity. So maybe we can call it "issues" or "problems" instead of "warnings", but it should fit into that list of map keys. > > > What do you think about it? Of course old symbols will be marked as > > deprecated and also logged that it is deprecated and removed in > > SLE13? > > Good solution. So, the target is CASP and/or SLE 12 SP3? For me target is SP3 as it need also adaptation in other modules and it also change behavior for warnings ( after change it will show popup even for warnings ) which is quite big change in behavior. > > Thx > Lukas > Thanks for notes Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
