On 05/04/14 12:02, Filip Kłębczyk wrote: > W dniu 05.04.2014 11:41, Thomas Perl pisze: >> 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?). > > Isn't there a private fork of Mer/Nemo in Jolla already?
Don't forget what Mer is about: "Making it easy to make devices". This is what I wrote about MeeGo: http://mer-l-in.blogspot.co.uk/2011/08/meego-and-hacker-community.html I think most of it is still relevant. So yes, Mer is *designed* to support internal builds and vendor-specific modifications. > Sorry, but this sounds like, either it will be "our" (Jolla way) or we are > taking toys and are going to different closed sandbox to play. I find it hard to correlate that with "lets talk about being more open". Lets not pre-judge. >> 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..). > > It all sounds great from practical point of view, but the real problem is how > things are pushed to Mer/Nemo without any discussion. Improving this should be on the agenda. That too much discussion does happen internally is partly what drove the meeting proposal. It's true that this should be addressed from the Mer side too. The fact is that most (not all) of the hours put into Mer are come from people who also work on SailfishOS and the lines blur. >> 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? > > That's all under condition that there will be any other vendors. If Mer/Nemo > will be totally controlled by one company in a closed way, don't expect any > other vendors to engage in anything. Oher vendors already participate and yet more will observe Jolla's experiences before commiting. >> 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 > > Sure, but that was part of Meego heritage and the fact Mer+Nemo was Meego > based. > But the future development of the project should be discussed in the open. > > Most importantly I think this whole discussion whether to merge Mer and Nemo > shouldn't take place here, but on Mer mailing list. It's like talking about > sth > that affects people, but not inviting them. This meeting is not about that subject :) That subject should/will be discussed on mer-general too. Yes there will be opinions from the SailfishOS community. Yes many people belong to both communities and don't always delineate cleanly or consistently. David _______________________________________________ SailfishOS.org Devel mailing list
