[Mageia-dev] what is this ????

Sat Nov 24 20:09:05 CET 2012

2012/11/24 PhilippeDidier <philippedidier at laposte.net>:
+> Sander Lepik a écrit :
+>> 24.11.2012 18:55, PhilippeDidier kirjutas:
+>>> NO !
+>>> You mean someone is paid and create a third repo for something Mageia
+>>> doesn't want to import...
+>>>
+>>> If that thing brings a mess into Mageia,  we will see bug reports in
+>>> bugzilla and lot of time lost by Mageia bug-triagers, devs, packagers,
+>>> before discovering that is not a Mageia problem but that this stuff
+>>> brought some shit !
+>>> We suffer of lack of time... and this will consume more time from
+>>> voluntary contributors to repair something badly done by someone that
+>>> was paid for it !
+>> Well, we have such repos already today and you can't stop something like that. But you saw
+>> my example the wrong way. Mageia doesn't have to support those repos and problems caused by
+>> such packages.
+> That has been a problem for Mandrake with Thac repo, a problem for
+> Mandriva with MIB repo... and sometimes it took a long (wasted) time to
+> understand that a reported bug was induced by something imported from
+> third repo.
+> NB plf repo was something else : mandriva devs worked on it !
+
+Still, we can't prevent that *. So perhaps should we:
+ - analyse it and find a clear model that explains it, so we can
+change what could be changed;
+ - even embrace it, that is, have a strategy to have more such
+external repositories to merge back into ours, or to better
+tag/mark/recognize what can come from something we do support as
+Mageia (because we produced it, or because it matches our
+requirements) and from something we don't.
+
+* it's a symptom that means that most of Mageia (as a whole product)
+works for some people, but some parts of it don't (so they
+duplicate/manage things on their own to make it quick, or more
+controlled for them).
+
+Still. The bottom line of having calls for bounties, people ready to
+pay to have some requests in Mageia answered in a more controlled way,
+is perfectly fine. Having them including in their requirements that
+the work be merged into (if possible), or made available to the parent
+project is even better.
+