[yast-devel] proposal warning levels
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 My suggestion is: drop notice level ( when passed, do not display it, just throw it away ) merge warning and error into one warning with current behavior of error merge blocker and fatal into one fatal with current behavior of fatal current usage of levels in git checkout: notice: 0 warning: 11 error: 3 blocker: 17 fatal: 5 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. 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? Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
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
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"?
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? Thx Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux Sent from my openSUSE Tumbleweed https://en.opensuse.org/Portal:Tumbleweed -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 15 Nov 2016 13:03:43 +0100 Lukas Ocilka <lukas.ocilka@suse.com> 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/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
On 11/15/2016 at 12:47, in message <20161115124752.3d0f74ce@pepa.labs.suse.cz>, Josef Reidinger <jreidinger@suse.cz> 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
My suggestion is:
drop notice level ( when passed, do not display it, just throw it away ) merge warning and error into one warning with current behavior of error merge blocker and fatal into one fatal with current behavior of fatal
current usage of levels in git checkout:
notice: 0 warning: 11 error: 3 blocker: 17 fatal: 5
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.
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?
I have always wondered about the warnings. Ideally, there would be no warnings as the UI should prevent the necessity. I do have some questions though. What are the possible warnings? 11 seems like a lot - perhaps we could reevaluate their necessity and reduce the number somewhat? Otherwise, I like your suggestions :-) Kenneth Wimer UI/UX Team Lead SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409 Nürnberg, Germany Phone: +49 911 740 53-669 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Josef Reidinger -
Kenneth Wimer -
Lukas Ocilka