[Mageia-discuss] About Mandriva tools future : Host Mandriva tools on github

[Thomas Lottmann]

  Le 01/10/2010 12:38, Fabrice Facorat a écrit :
> I've been following closely all the Mandriva vs Mageia story. I found
> it unfortunate that we have to come to this way, but I guess there's a
> serious fracture between Mandriva and part of its community. We have
> no choice except to cope with this and try to do our best to allow
> this unfortunate situation to found a sensible solution in the future.
>
> As we know, one of the Mandriva strenght are the Mandriva tools,
> however Mandriva tools have some issues :
> - they are written in perl. Sorry for perl dev, but I do still think
> that perl is harder to understand than C-like based syntax langages.
> However we must admit that we are not going to rewrite all the
> Mandriva tools ;-) However better documentation ( PerlDoc tags ) could
> help a little.
>
> - Mandriva tools are not used by others distributions ( except
> PCLinuxOS, United Linux, and ... Mageia ) and so have few external
> contributions : They notably lack visibility.

I do agree with this.

> I do think also that Mandriva will have to use its ressources in an
> efficient way.
>
> Here aree my proposals, feel free to discuss :
>
> 1. host Mandriva tools on github or code.google.com. This will ease
> fork maintenance and tracking, to contribute back ( without having to
> have a Mandriva account )

Yes. Having their own 'site' and independent platform may help.

> 2. Make some decisions about the tools we should keep, and the ones we
> should ... trash. For example we did replace printerdrake with
> system-config-printer ( python ), and msec have been rewritten (
> python ). Whereas I do think that system-config-printer is way buggier
> than printerdrake, I guess that at some points, we will have to do
> this more and more : replace some Mandriva tools with for example some
> Fedora ones. Please note however that this bring its own issues :
> python vs perl, and the integration with the rest of Mandriva
> infrastructure

We need to see what is still functional, what is broken (and so what is 
to repair), and what is to drop. Eventually, what is to support and 
repair again (printerdrake?) if possible.

For what I know, there are many tools that work : RPMDrake and related, 
Drakstats, Diskdrake, Harddrake, DrakX11, Drak3D, DrakUPS, DrakFirewall, 
DrakGuard (wonderful this one) but may networking tools to share network 
or use VPN, Samba, NFS, WebDav, and eventually along with Diskdrake, are 
broken. Others such as Draksnapshot and DrakSamba (not sure if it works 
or not) are a pain due to insufficient functionalities or 
outdated/painful GUI. There is a nice theming functionality in the MCC 
that is also probably broken or difficult to use, that could be restored 
or explained.

> 3. A decision will have to be made concerning net_applet and NetworkManager

Yes, even though I think we should give another chance to NetApplet and 
see what should be fixed to make it better. NetAppler has the advantages 
of being linked to DrakFirewall, perhaps other tools, and to be 
independent of any environment.

> 4. Whereas I do love rpmdrake, I do think also that something will
> have to be done about it as its UI is clearly outdated and not on par
> with the competition :
> - Ubuntu software center :
> http://seilo.geekyogre.com/2010/09/software-center-with-a-dose-of-zeitgeist-and-maybe-teamgeist/
> , http://en.wikipedia.org/wiki/Ubuntu_Software_Center ,
> https://wiki.ubuntu.com/SoftwareCenter
> - iTunes App Store :
> http://www.askdavetaylor.com/how_to_download_iphone_apps_from_apple_itunes_store.html
> , http://cybernetnews.com/download-iphone-firmware-20-itunes-77-app-store-and-more/
> - Interesting discussion about PackageKit direction :
> http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/
>
> So we may have to completely rewrite rpmdrake UI or switch to
> packagekit with and urpmi backend.

I still have a very strong faith and appreciation for RPMDrake. I really 
think it is well designed and intuitive, despite it's little issues and 
being slow (honestly, PackageKit is slow and also has issues so...).

The real issue that RPMDrake has is it's Aplications with GUI filter. 
Even if I think this functionalitiy is really good for beginners, 
RPMDrake is a -package- manager. Mandriva does need a real and dedicated 
Application manager (could be called an AppCenter) where beginners would 
find a way to install (shop?) applications with a very nice layout, 
presentation, clear icons, screenshot, and no irritating choice of 
hundreds of dependencies with barbaric names.
It might be difficult, but much more convenient for those who just want 
things to work in a snap (or in very few clicks).

This would allow to place back again the default filter on "All" (should 
be renamed to "Show all packages") for the RPMDrake package manager. We 
would then have an AppCenter and a real package manager for advanced 
package management, without forgetting a dedicated tool with GUI to 
manage orphans more efficiently.

Yet, all of this demands a huge lot of work and we will need huge 
resources...

> 5. Junior tasks contributions. I noticed while visiting the
> LibreOffice website. They have junior task for people willing to
> contribute to the codebase, and most of theses junior tasks consist to
> improve code clarity, fix comments. I guess that the same thing could
> be done with Mandriva tools, notably adding perldoc tags/comments.

Yes. This will help people from outside understand better how the 
program works. Reading the code itself isn't that easy even if it is 
well written.

> Last but not least, I know that on Mageia ML, there was a discussion
> about the people we should target. Here are some interesting
> reflexions :
> Sweet Caroline : http://mairin.wordpress.com/2010/09/02/sweet-caroline/
> fedoraproject.org redesign update :
> http://mairin.wordpress.com/2010/09/03/fedoraproject-org-redesign-update/
> You must be this tall to ride: __ :
> http://mairin.wordpress.com/2010/10/01/you-must-be-this-tall-to-ride-__

Will read them when I'll find the time to...

Thomas.