Mailinglist Archive: yast-devel (55 mails)

< Previous Next >
Re: [yast-devel] proposal warning levels
On Tue, 15 Nov 2016 13:03:43 +0100
Lukas Ocilka <lukas.ocilka@xxxxxxxx> 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: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >