Hi, You've proved my point :-)
Knowing the policy is one thing, but knowing for each individual plugin the reason(s) why it's not in "good" would be useful. Especially the "ugly" ones. I think you've proved my point, because the lirc plugin is GPL only, thus in ugly because it doesn't comply with the dual license model. That would be useful to have written down inside the plugins-ugly package itself, as that's not likely to change. Oh, and the Bundle Policy details the 4 gstreamer plugins bundles, but elisa doesn't have a "base", nor does it include plugins in the main elisa package which might be considered as the equivalent, so maybe that would be worth noting there too (to keep users from wondering why they can't find the "base" set of plugins ;-)). Matthias Philippe Normand wrote : > Hi Matthias, > > You can find some documentation about the split in > docs/bundles_policy.txt > > About the LIRC plugin, I think it could be moved if it had at least > functional unittests, which is not the case. > > Philippe > > Le mercredi 15 avril 2009 à 10:43 +0200, Matthias Saou a écrit : > > Hi, > > > > I've been looking at the ugly plugins recently, and I just can't figure > > out for sure why the lirc plugin is in there : It's GPLv3+ and it > > doesn't do anything "questionable". Hence what I ask for in the > > subject : Would it be possible to detail inside each plugin, or at least > > in a text file inside each group of plugins (good/bad/ugly) the > > reason(s) why they are where they are? > > > > I've looked at the other plugins in ugly and don't know for sure why > > they're there either. It's not a license issue, so I'm just guessing it > > must be because of the way they connect to remote services. But again, > > I'm not sure. > > > > Matthias > > -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 10 (Cambridge) - Linux kernel 2.6.27.21-170.2.56.fc10.x86_64 Load : 0.33 0.33 0.29
