[Mageia-dev] Proposed Feature:UiAbstraction4mcc

[Frank Griffin]

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.