Mailinglist Archive: yast-devel (79 mails)

< Previous Next >
Re: [yast-devel] The Business Case for Y-Storage - Proposal vs. Device Graph
On Wed, 2 Mar 2016 17:43:36 +0100
Stefan Hundhammer <shundhammer@xxxxxxx> wrote:

Following up on the "Refactoring madness" thread and an IRC
discussion; I had written lately:

"this is an approach I don't like at all because it focuses on the
wrong thing: All that stuff is not about creating device graphs. We
are not in the business of making or selling device graphs. Device
graphs are just a tool for what we really intend to do. Concentrating
on an irrelevant (or, to put it less harshly, behind-the-scenes) tool
is most misleading for anybody looking at that code."

I was asked to elaborate that point further, so here we go:

What is the point of what we are doing in that new yast-storage-ng?
This is really all about making a storage proposal for our
installation workflow; this is the main purpose of it all, with more
specialized issues like the expert partitioner aside.

In most of the history of YaST2, we had the concept of providing the
user with a useful, reasonable "proposal" for each aspect of the
Linux installation. It was always intentionally called "proposal"
because it is not set in stone; the user can always change it if it
doesn't fit his needs.

So we've been doing some calculations based on hardware probing,
based on product parameters (control.xml), based on guessed values
for every aspect of the installation: For the bootloader, for the
software selection, for the desktop etc. etc., and for storage: What
partitions to remove or to resize to make room for Linux, what new
partitions and file systems to create, where to mount them.

So the term "proposal" is a well-known concept in the YaST
installation for YaST developers as well as for other people in SUSE
R&D, including product and project managers, and even for some
advanced users.

So, when looking through the installation code, I would expect that
to be somehow reflected in the code; I'd expect a class
"StorageProposal" somewhere, preferably with a main method
'propose()'. And it used to be like that in my first version of that
new storage proposal.

Question is if it is expected also by others as current way is having
module with given name and method Propose (currently in yast code is 44
method Propose ) or client called _proposal ( even more now ). Checking
for current number of Proposal class is a bit hard as it is also name
of _proposal client.
So e.g. myself I expect something like Storage.propose which hides
details inside.
Not mandatory note, just to be aware that expectation can be different.


But not for long: It was changed very soon to a class
"DevicegraphGenerator". There is now also a class
"RefinedDevicegraph". One thing that is no longer present, though, is
anything with "Proposal" in the name.

As written above need not to be problem as long as there is something
like Storage.propose. Not everything have to be name. For me Proposal
class is more like functor that is more functional then object. Object
is for me Storage configuration represented by class Storage, that can
be read/written, proposed, import/export.


To me, this is not only not self-explanatory (as good code should
be), it is outright confusing. Anybody searching for the place where
a storage proposal is made will have to do a lot of grepping to find
where it happens, and so far every was vers much surprised (to put it
mildly) where this was.

Anybody searching is a bit strong statement, do you do some User
testing or research regarding it?


That's misleading IMHO. Device graphs are a useful tool in that
context, but just that: A tool. They are not the central part around
everything revolves, at least not from the perspective of a developer
using that part.

yes, tool. For me the most important starting point of class
representing Storage configuration which can contain graph holding
information about configuration that can be queried. For me graph is
not tool, for me it is object holding storage configuration that allows
querying and modification of that configuration. To be honest I do not
think it need to contain graph word in it, but currently don't have
better name for it.


That's why I had written that we are not in the business of making or
selling device graphs, we are in the business of making useful
proposals. I miss the whole concept of proposals here. There is only
one function in the DevicegraphGenerator called proposal(), and even
that was only named like this after several people had agreed that
run() is not a good name, in particular when you have a run()
function in several classes (good luck finding the right one with
'grep'!).

I agree with you, that "run" is very bad name as it indicate Functor
overusage indicating procedural programming. So as I said I expect
something like Storage.propose that do proposal.

I also agree with you that DeviceGraphGenerator is not where I start
searching for proposal. Probably DeviceGraphGenerator is bad name and
something like StorageConfiguration is better with method propose,
system ( for system wide configuration ) and something like target_one
method ( better name can be found for sure ) is what can be useful.

Actually maybe not convenient for Yast, but more intuitive for me as
system can do lazy "Read" and for target_one should be method write,
which write that target one to system.


So, what we are doing now is to put very much emphasis on an
implementation detail while omitting the well-known concept.

well known concept - I try to google "proposal concept", "programming
proposal concept" or "IT proposal concept" and nothing return my
anything useful. So maybe it is well known only in SUSE or maybe YaST.

What is currently closes query that brings me similar to topic is
"default values" which mention it. Do maybe we should stop living is
small yast pond and look elsewhere what is actually well known concept.
And what actually yast do is that it calculate default values for
installation which is understandable even outside of yast, suse or
linux world.

So I fully agree that DeviceGraphGenerator.proposal or run is not nice
name and I agree that some StorageProposal.run or propose is better, I
still feel that it is not good enough solution as it is not intuitive
as Storage.propose or StorageConfiguration.proposal which is the first
idea when to search when we speak that we want to propose default
values for Storage configuration.

It is similar case like if we took base OOP example with cat and #say
method and we propose to use something like

AnimalSpeaker.say(cat) instead of cat.say

Josef



Kind regards

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
References