[Discussion Thread] Merging Mer and Sailfish OS

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.

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.

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.

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

@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? :)

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

I am such an idiot.

:D

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)

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

vattuvarg what worries do you have?

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.

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

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

https://build.merproject.org/project/show/sailfishos:chum:1.0.1.10

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 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. :)

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!)

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

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 Yes, that's why I said "usefull for (edit) Jolla" ;). Anyways my discussion was oriented to the open-source components.

@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)

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 :)

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

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

@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.

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"?

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

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

Can we hope for the missing features of maemo N900?

Nothing, nemo can continue on much as they are now