We have moved to a new Sailfish OS Forum. Please start new discussions there.

[Discussion Thread] Merging Mer and Sailfish OS

asked 2019-04-03 13:09:36 +0300

James gravatar image

updated 2019-04-03 17:05:22 +0300

rozgwi gravatar image

This thread was created to discuss about the announcement made in our blog regarding the merge of Mer Project with SailfishOS. Read the full blog post at https://blog.jolla.com/message-in-a-bottle/.

Some highlights discussed in the blog post:

  • Merger of Mer Project with Sailfish OS

  • User identities and an open workflow with community contributions and bug reports.

  • Privacy of the users

Tomorrow (April 4th 2019 at 09:00 UTC) we will also be discussing it in the Community Collaboration meeting on IRC with David (lbt) present to answer any questions you guys may have. Link to the meeting planning page: together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning



edit retag flag offensive close delete

9 Answers

Sort by » oldest newest most voted

answered 2019-04-03 17:14:10 +0300

rozgwi gravatar image

updated 2019-04-03 17:16:31 +0300

How does bug tracking tie into this, exactly?

Personally I'm convinced that Jolla would profit significantly from a decent public tracker.
TJC/Askbot is anything but suitable for reporting and tracking bugs or feature-requests. Look at the sheer number of duplicated or forgotten questions. About the internal tracker at Jolla I can't say anything but having at least a part exposed to the community would additionally help communication a lot.

Maybe there will be an opportunity for such a thing during this merger?

edit flag offensive delete publish link more



Yes a bug tracker is something we're talking about in the context of this merge.

TJC is working pretty well for high level user issues and feature discussions with the OS - what we don't have is something for the open source code.

lbt ( 2019-04-03 17:48:03 +0300 )edit

For the record, it's certainly possible to have a single Bugzilla instance that host both private and public bugs as whole bugs and even individual comments can be marked as private and accessible only to certain group/s.

And this is not a theoretical option, but something that has been used in production on many Bugzilla instances for years, such as on bugzilla.redhat.com, which host bugs for both Fedora and Red Hat Eenterprise Linux.

MartinK ( 2019-04-04 06:18:40 +0300 )edit

I would argue against using any type of Bugzilla or Bugzilla-like interface if you're going to expose it to users, in any case. It's a really, really badly designed piece of software (even version 5.0) where everything is either hard to find or hard to do, and many large projects have now started using software like GitLab - which also allows for both private and public bug reports as well as repositories, has lots of useful features and is easy to use in general for both users who want to report a bug and developers who want to fix it.

nthn ( 2019-04-04 10:50:21 +0300 )edit

then again more people engage with togetherjolla than they would with a bugzilla page as this carries more of a community feel.

Mariusmssj ( 2019-04-04 10:51:36 +0300 )edit

@nthn - you make a very valid point .... but :)

The problem is that we're not starting from scratch. Jolla uses bugzilla internally and is heavily invested in it including modifications that keep track of time spent on bugs and allocations to customers etc. Clearly that's not going to change - nor is access to it going to be opened up.

Now we could try and use a completely new bug tracker in the open or we could have a bugzilla instance.

If we went with a new system then we'd have to automate connectivity to our internal BZ (which must be used by sailors) and it's likely that we'd have limited resources to spend so it would be quite a minimal interconnect and feedback would be low and most actual 'work' would continue to happen internally.

OTOH if we went with an external instance of BZ (and we've looked at this) then we could actually replicate/sync bugs across the 2 systems to provide much more visibility of the work being done. This means both the BZ would be active and updated when sailors or community made changes to the bug

So... which sounds better now? :)

lbt ( 2019-04-04 11:15:40 +0300 )edit

@Mariusmssj exactly - so I'm thinking that tjc is a much better place to discuss and debate features and issues with using SFOS. The bug tracker would likely be for code level bugs.

lbt ( 2019-04-04 11:21:18 +0300 )edit

@lbt, Thanks for your reply, that's definitely true, although I still think and can reasonably demonstrate that Bugzilla is a huge hurdle to overcome for submitting or contributing to a bug report. If you look at any public GitLab instance, or GitHub, or other user-friendly alternatives, you can see lots of regular first time users submitting decent bug reports by filling in the existing templates, reporting back with new findings, replying to questions asking for more information, and so on - naturally not all user comments are as useful as the others. Take a look at any Bugzilla instance, and... nothing. Nowhere near as many bug reports, nowhere near as much interaction, most reports are made by developers themselves, and keeping track of how much progress, if any, has been made is really difficult.

I can understand that you wouldn't want to set up a new public bug tracker that's only barely connected to the internal one, but perhaps in the long term it's worth looking into upgrading the internal affairs away from Bugzilla, and then you could set up a single tracker for both internal and public use, which would benefit everyone. A higher visibility and accessibility leads to more and better reports, and by extension to more contributions from the community. At least the existing bugs and comments can easily be transferred from Bugzilla to GitLab, it's 'only' the modifications that would need a lot of work.

nthn ( 2019-04-04 11:53:54 +0300 )edit

answered 2019-04-03 13:17:12 +0300

Kopekenscheich gravatar image

Could anyone please outline the benefits of this for Dumbo user me?

edit flag offensive delete publish link more



The primary benefit is clearly stated in the blog post: "colours of the websites will change"

spag ( 2019-04-03 16:22:30 +0300 )edit

I am such an idiot.

Kopekenscheich ( 2019-04-03 16:29:06 +0300 )edit


I really should update the CSS to change the colours shouldn't I

see my comment to iaubblaeser (that post had more specific points so I answered there)

lbt ( 2019-04-03 17:43:12 +0300 )edit

I worry that the opensource project ends up behind a company veil.

vattuvarg ( 2019-04-03 17:48:52 +0300 )edit

vattuvarg what worries do you have?

lbt ( 2019-04-03 18:01:57 +0300 )edit

answered 2019-04-03 17:29:39 +0300

laubblaeser gravatar image

While this merging may make sense, especially in terms of a common bug tracking system and a more unified CI, I still would like to ask a few simple questions:

  • What are the benefits for the end users?
  • Will there be any changes in the way communication to the user base will work?
  • Will there be any changes in the functionality of SFOS or even a change of pace in the development cycles?

Thanks in advance for your answers and thoughts on these questions.

edit flag offensive delete publish link more



One benefit is in keeping everything together - the Mer project and community used to be distinct from Sailfish OS. This made sense years ago but nowadays there's really only one community so this acknowledges that evolution.

I doubt you'll notice any communication changes - I/Mer hasn't really made any for quite some time :)

No, this merge isn't going to affect SFOS or development cycles directly.

Another key benefit is that this change does extend the Sailfish OS community more towards the code.

lbt ( 2019-04-03 17:40:59 +0300 )edit

Straightforward and easily understandable answers. Thank you very much for the quick response. :)

laubblaeser ( 2019-04-03 17:42:53 +0300 )edit

answered 2019-04-04 06:45:56 +0300

MartinK gravatar image

With Mer merging with Sailfish OS we now have both the public build system (previously Mer OBS) and the main repository/store under one roof, right ?

It would make perfect sense to finally combine those two and make it possible for native application developers (which are overwhelmingly FOSS anyway) to build and submit their packages in source form through OBS directly to Jolla Store/Harbour.

Any sane Linux distribution does builds the binary packages it distributes this way, as well as other projects, such as FDroid or Flathub. It has the substantial benefit of tying the binary package to its source code, that not only makes it possible for interested parties to inspect the code for malware or other security issues, but opens other possibilities such as mass-rebuilding all such packages on an upcoming new Sailfish OS release to check for unexpected API changes (such as the previously unannounced libpython.so version bump that broke OKBoard and other applications linking to the Python 3 C API).

edit flag offensive delete publish link more



ROFL. You mean how I set up 'Chum' starting with release and updated with every SFOS release since :)


Openrepos went their own way with binary uploads very early and the community followed.

If people in the community want to move in this direction then I'm happy to help setup OBS projects etc

lbt ( 2019-04-04 11:57:37 +0300 )edit

@lbt Yep, I know about Chum, but AFAIK that was basically just a first step of something bigger, right ? The next steps - a community QA process/interface/CI & any sort of Jola Store or Open Repos integration simply never happened as far as I know. But I might be missing some things or remembering things wrongly after all that time.

In any case Chum could be certainly a good starting point of something that would move Sailfish OS closer to a proper Linux distro package build workflow. :)

MartinK ( 2019-04-04 14:51:57 +0300 )edit

could you explain what chum is? I LIKE this idea as I dislike random binary uploads but I think this would need some more docs and simple tutorials if this is the way forward (it should be!)

simonschmeisser ( 2019-04-07 11:15:02 +0300 )edit

answered 2019-04-03 20:13:19 +0300

tortoisedoc gravatar image

This is great news for MER for sure (? I hope ?), can we also have a proper contribution guideline (im thinking git comment standards, development strategy as in branching standards etcetc)? It will ease working together alot.

edit flag offensive delete publish link more

answered 2019-04-03 16:34:04 +0300

ApB gravatar image

As an end user i don't think it will affect me much. I believe stuff will still be slow and quite hard to be integrated in the main OS (Sailfish). Its all about resources in the end.

edit flag offensive delete publish link more



Actually I can tell from experience; if what you are trying to merge is valuable for MER / SailfishOS / Jolla, it will be merged pretty fast by the sailors.

tortoisedoc ( 2019-04-03 20:11:44 +0300 )edit


I can think of one or two things that would be be beneficial to SFOS (ie the backbone to PureMaps and Modrana) but jolla is happy with other solutions (Here Android in the case of maps) or focused on other stuff. And apart from that for many stuff we'll need UI stuff in the settings of the main OS. Quite difficult to get stuff in there.

ApB ( 2019-04-03 20:41:31 +0300 )edit

@ApB Yes, that's why I said "usefull for (edit) Jolla" ;). Anyways my discussion was oriented to the open-source components.

tortoisedoc ( 2019-04-03 20:59:08 +0300 )edit

@tortoisedoc Jolla is focused on its clients. The users might have other needs that jolla cant focus on (resources). Yet even if a user has the knowledge and can put the work in the merging process is slow. If things were faster SFOS would be a better OS. And maybe we wouldn't have a fragmented ecosystem (store/openrepos)

ApB ( 2019-04-03 21:10:37 +0300 )edit

answered 2019-04-04 06:36:41 +0300

MartinK gravatar image

So if I understand things correctly, it will be possible to use a Jolla account for the previously-Mer-owned infrastructure, such as for OBS and the Bugzilla, right ?

That could be quite an improvement as Mer account registration has been disabled for quite a while, requiring manually asking one of the main Mer maintainers to get a new account. Removing this hurdle could improve the contributor count by lowering the barrier for entry.

edit flag offensive delete publish link more



That's correct. We're going to move to using the Jolla accounts system to authenticate. A lot of users have the same username/email so they're easy. We'll set out the plan for other users over time (it's a bit complicated to put in a simple comment) The main thing is to stop someone registering a username on Jolla accounts and 'taking over' an old Mer account with the same username. Oh, we're also not just 'moving' accounts from Mer to Jolla as that's not respectful of people signing up for an open source community project and then being forced into a company controlled accounts database. Also - it's not a big deal to just ask me for an account. People have been doing that and will still need to until we get things in place :)

lbt ( 2019-04-04 11:49:30 +0300 )edit

If this means that we get rid of the MER bugtracking, that'd be awesome

tortoisedoc ( 2019-04-04 18:02:19 +0300 )edit

answered 2019-04-04 20:00:36 +0300

cl_ix gravatar image

Does this merger mean that Sailfish OS will now include proper X11 support?

edit flag offensive delete publish link more



Is X11 still that important? I though the whole point was for Wayland to replace it

Mariusmssj ( 2019-04-04 20:33:23 +0300 )edit

@Mariusmssj most people complaining about stuff like that would be happy if they could write a small program in the terminal each time they had to make a phone call. They have zero understanding of user needs.

ApB ( 2019-04-04 20:56:52 +0300 )edit

Apart from attacking X11 with no factual evidence, what is the point of your comment? Should Jolla remove the terminal application and developer mode since those go against your concept of "user needs"?

cl_ix ( 2019-04-04 22:46:41 +0300 )edit

It doesn't have X11 support now, so I don't see why that would change. This is mostly a rebranding exercise, the end product will still look and act the same.

I'm not even sure its possible to have X11 running with hybris graphics

r0kk3rz ( 2019-04-05 02:19:24 +0300 )edit

Which sounds right - the Mer gitlab account has forked XServer repositories that haven't been updated/used in over 4 years. I own a GeminiPDA, and X11 works reasonably well with libhybris on Debian. Ironically, SailfishOS remains in a quite damaged and problematic state on the same device. If anyone is interested in XWayland on Sailfish, check out this page

cl_ix ( 2019-04-05 04:48:27 +0300 )edit

answered 2019-04-04 23:19:03 +0300

nadir gravatar image

So if Mer is being merged with Sailfish OS what happens with nemomobile?

edit flag offensive delete publish link more


Can we hope for the missing features of maemo N900?

chris_bavaria ( 2019-04-05 00:22:55 +0300 )edit

Nothing, nemo can continue on much as they are now

r0kk3rz ( 2019-04-05 02:16:59 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2019-04-03 13:09:36 +0300

Seen: 2,385 times

Last updated: Apr 04 '19