[Mageia-dev] Proposed Feature:UiAbstraction4mcc

Wed Jun 13 14:48:26 CEST 2012

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.
+
+
+