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.
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.
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.
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.
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'!).
So, what we are doing now is to put very much emphasis on an implementation
detail while omitting the well-known concept.
Kind regards
--
Stefan Hundhammer