On Tue, 15 Nov 2016 13:03:43 +0100
Lukas Ocilka
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/insta... 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/93d41b2891706e779bab9e921c5f8693e... 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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org