On 05 Apr 2014, at 10:21, Thomas B. Rücker <tho...@ruecker.fi> wrote: > Reading this I can't help but wonder if Jolla now claims ownership of > Mer/Nemo then. Even with fancy hat changing. Bringing this discussion up > in a strictly Sailfish context implies this.
Personally, I see it more like “claiming maintainership”, if anything - maintaining a set of well-maintained and packaged middleware components in Mer that other projects can decide to use or not (the alternative would be to have a private/downstream fork of Mer/Nemo and not contribute to Mer/Nemo - would that be better?). My personal MW turf for example is SDL 2 and Python 3 at the moment, both of which are currently in SFOS Nemo Middleware. Pushing those (very generic, even non-mobile-related) middleware components from Jolla’s Nemo Middleware or non-Jolla Nemo Middleware to Mer means that Mer will have those two properly maintained middleware bits /in its repos/ instead of in some vendor-specific downstream distribution (and not available in Mer at all, or unmaintained in Mer, etc..). With three hats on (package maintainer, application developer and end user), I think having more maintained stuff in upstream Mer is a good thing: - As a package maintainer, I could do work in Mer and contribute to all downstream users equally (indirectly), and don’t have to worry about pushing updates to 10 different distros/repos, or working only in a single vendor-specific downstream fork/repo of Mer - As an application developer, I can develop against middleware in Mer and easily port my application between Mer-using products, without having to worry that the middleware component I am using isn’t available in a certain product/distro or is outdated/broken/unmaintained there - As an end user, I am benefitting from the above points with more apps, as applications developers have an easier time porting to and between Mer-based products and more confidence coding against a given middleware component. Also, I can use my knowledge of middleware tools (say, systemd’s “journalctl” or the “ssu” utility) on Mer-based products without having to figure out what every distro/product is using Other vendors and projects can still choose to not install or pull in those middleware packages (or provide their own versions of it), but more packages being available (and maintained!) in Mer instead of only in a vendor-specific Mer snapshot/“fork” is a good thing? “Vendor-neutral” sounds nice in theory, but in practice even in Mer right now, there are certain “vendor-specific” decisions made (the Linux kernel, systemd, glibc, zypp, RPM, Qt, to name just a few) that favor one project over others - and that is a Good Thing (even if I would sometimes like to see some components replaced with others, having maintained, constantly-improving sub-optimal stuff is IMHO better than having eventually-perfect, longtime-stagnant, vendor-neutral, perfectly-generic pre-proof-of-concept “ideas” floating around [yeah, I’m exaggerating a bit here]). HTH :) Thomas _______________________________________________ SailfishOS.org Devel mailing list
