apache spark, anyone?

[Peter MacKinnon]

On 7/27/15 4:00 PM, gil wrote:
>
> hi
>
> Il 27/07/2015 21:26, Haïkel ha scritto:
>> This is a good case to show that we need layered products on top of Fedora.
>> If we want to keep Fedora relevant in the big data field (and many
>> others!), we have
>> to accept "second-class" repositories with less restrictive guidelines (hence
>> quality).
> i disagree, if it's at the expense of quality
We are already sacrificing quality in the way that project deps must be 
shifted and features excised just to get/keep something packaged in a 
current release. We can't claim better quality in our Fedora Big Data 
packages than the upstream bundles, tarballs, rpms, etc. We have 
actually had people at conferences tell our developers that they would 
never use our Big Data packages like Hadoop precisely because of the way 
it is constructed. They wouldn't trust it.

>> I'm in favor that we allow approved SIGs to ship in separate
>> repositories packages
>> that does not strictly follow some guidelines. Granted that fesco/FPC allow them
>> to lift *identified* guidelines for valid reasons.
> but this repository are already present? i mean "rpmfusion" ...
>> ---
>>
>> It's not realistic to think that we could ship big data stuff without allowing
>> bundled libraries. It's not how the java/hadoop ecosystems work at all,
>> and it's unlikely to change.
> i disagree, bundle libraries are really a crap ... sorry. this to me 
> means that the
> project or the developers who use them are low-level, and the software 
> that
> uses it loses value and my interest
>> Requesting bundle exceptions from FPC for every big data package would
>> jam the process. I would suggest that the big data SIG coordinate to maintain
>> a copr repository until we find a satisfactory solution.
>>
>> H.
> this is the rule, god bless FPC :)

I fear that we are tilting at windmills here. Containers and projects 
like Atomic and CoreOS are redefining what application composition can 
look like. The base OS is no longer driving this since I can compose an 
application with containers that could be a fabulous mix of components 
running on Fedora, CentOS, Ubuntu, and so on.

Language ecosystems have evolved for delivering applications. But they 
_are not reliant__nor interested_ in the whims of any particular distro 
packaging rules. I have an uber jar with my application and its bundled 
runtime dependencies. Do you have a current compatible JVM? Great! Let's 
get work done!

But it's not clear that Fedora is evolving. The CVE paranoia only 
travels so far up the stack to a point _where the value of the 
application __outweighs the security risks of having multiple log4j 
versions installed_. A "conform or be cast out" ethos is the road to 
irrelevance IMHO.

My $0.02
\Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/bigdata/attachments/20150729/862a1402/attachment-0001.html>