Le lundi 22 juillet 2013 à 09:38 -0400, Matthew Miller a écrit : > And third, by increasing our engagement upstream, we can reduce our own > work. For example, right now RubyGems.org doesn't do any validation of > licenses, basic review for malware, or gem signing. If we knew that this > basic diligence was happening upstream, we could extend our circle of trust. > We've long had the mantra of "upstream! upstream! upstream!" for code and > patches — we can do the same thing for packaging, for the same reasons and > for similar benefits. (But to do that, we need to work with upstream > packaging formats rather than demanding RPM — because experience shows that > that doesn't work.) I am quite doubtful about this part. What interest most people pushing gems to github or anywhere is the low barrier of entry. By pushing our contraints upstream directly, I think we may go against the wish of those developers. There is a whole movement on "no copyright", and we know this doesn't work like this unfortunately ( see SCO case, for example, and even if newer developers do not seems to care, I am old enough to remember ). And that's not that rpm is overly complex ( even if it could be simplified, and work on this front is going quite well ), it is all the rules around that make stuff more difficult. So if we decide to push the rules upstream, let's say on pypi, unless a huge part of the whole community start to check everything, I doubt we can have the same level of confidence on the whole set of modules. So in the end, we would still need to either : - be able to fix/correct metadata on every modules, or negociate with upstream to have them fixed - be able to filter and remove the one that are not good. We can make sure this scale for part that can be automated ( as perl/cpan did with kwality testing, and the whole feedback and cpantesters idea ), but we still need a manual inspection for various stuff, and there is likely less people interested into reviews than coding. So the question is "how do we convince people who are not convinced yet of the added value of such rules ?" -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
