On 06/13/2012 08:06 AM, Guillaume Rousse wrote:
Le 13/06/2012 13:59, Steven Tucker a écrit :
Just to be clear, I am not suggesting that we port Yast to Mageia, I am
suggesting we use its Ui abstraction only. I use Mageia over openSuse
for many reasons, but I do admire how well Yast works, and would love to
see similar in Mageia. Perhaps we could start planning the next
generation of MCC ??
I guess you're volonteer to do the porting work, and to maintain the
tools thereafter. Otherwise, that's moot.
In ten years of contribution to mandrake/mandriva/mageia, I've seen
several similar proposals to rewrite those tools for "better graphical
consistency with my prefered desktop (tm)" or "better maintainability
unsing more adapted languages (c)". Unfortunatly, the level of actual
contributions to the code to reach those marvelous goals barely
reached the verbosity of the discussion on the mailing-list...
While i sympathize with the "I've seen this before" reaction, it seems
to me that Steven has actually looked into this at the code and
implementation level, so I wouldn't be too quick to blow it off. Some
other things to be considered are:
1) MCC tools and the install are the two crown jewels that differentiate
MGA/MDV from other distros. As such, they deserve more attention than
they get.
2) How maintainable is the current code ? From the bits and pieces I've
seen over the years and comments in this ML, it has the reputation (with
the exception of urpmi/rpmdrake, which sees active development) of being
hyper-abbreviated perl code that no one works with unless forced to.
Some standardization and modularity probably wouldn't hurt. It's a lot
easier to find one person who groks drakconnect and other people who
grok Gtk, Qt, and curses than to find one person who groks all of them.
3) The people who currently work in the code for these tools aren't
going to be around forever. Anything that makes the code structure more
accessible to new developers ought to receive, at the least, serious
consideration.
In this case, the proposal has the advantage of being able to be
implemented in stages, one tool at a time. I think it would be a
productive exercise for those who know the code to respond with a sketch
of what the work would entail, with the expectation that the actual work
would be performed by those suggesting the change. Packaging isn't the
only MGA activity that benefits from the mentor/apprentice approach.
