Changes needed to merge the project names to Sailfish OS

Announcements
#29

What I said is “significant contributor”

Indeed, sorry about that, apparently g7 is a major contributor, I’m not sure what way of PNGing his contributions from github will be ‘non-sided’ by you, but it seems like 10-15 lines of code in the last 3 months, not a main contributor to any of sfos packages, pls correct me if I’m wrong, he might be a cool guy and an awesome contributor, but neither a huge contributor for sfos, nor a BIG GUY FOR YOU. The guy “running away from Jolla’s latest acknowledgement” is neither big, nor interesting.

@rinigus This is neither personal, or non-personal, kabouik is selling a lot of shit that is not personal while he pretends to be the ‘seller’, he’s not, if you think pretending like this is OK, cool, but I do not avow

#39

Perhaps this could be some reasons why Jolla is moving away from OBS:
https://specs.openstack.org/openstack/fuel-specs/specs/7.0/replace-obs.html

4 Likes
#40

As far as I understood, the reason for OBS removal is primarily legal. People are uploading whatever and Jolla may be held responsible for hosting illegal content or something along those lines. You can’t beat that sort of argument :frowning:

IMO it should stay around at least to allow outside developers to make reproducible builds of their Jolla Store apps. I don’t think my opinion weighs much, though…

8 Likes
#41

@slava, I presume it is not an official reply and from your response it sounds like the reasoning was not fully discussed in house among Jolla developers.

I am not aware of anyone pushing something illegal at OBS. I presume we are talking about Android binary blobs here. Or anything else?

Again, if it is for legal reasons, those have to be stated and not plastered over by something irrelevant. When we get the reasons behind considering closure of OBS, we can start the discussion regarding it and how to find the solution that would work for the all parties involved.

9 Likes
#42

Just conspiracy theory: Last year I saw increased amount of attacks to build environments and other internal systems in various technology companies. When such attack is successful, you have to shut down such environment and don’t release details until investigation ends.

4 Likes
#43

I’ve created a separate topic of the OBS shut down and next steps I’ve tried to describe the rationale behind the decision. Please use that thread for ideas, questions and discussion related to this topic.

6 Likes
#44

The mer wiki (https://wiki.merproject.org) also seems to be regularly down. Is this also because of this change? Parts of the merwiki contained useful information, such as the current community adaptations, information about how Spectacle works and such.

If this is related to this topic, are there plans to make the content of the wiki available once again, albeit on its original location or somewhere else?

4 Likes
Sailfish OS and phones
#45

wow, wiki with https://wiki.merproject.org/wiki/Adaptations/libhybris table was really shut down? Are you…? Can’t believe this.

1 Like
#46

There’s just a problem with the disks on the machine hosting the wiki. I’ll try and get it back up ASAP.

7 Likes
#47

aaaaand it’s back up

8 Likes
#48

There’s a typo in your link - the word “project” should have an ‘r’ in it. So don’t be surprised if the site seems to be down if you try to follow your link :wink:

3 Likes
#49

Is there some time plan for migration to https://github.com/sailfishos ? I would like to send some patches to connman, but I don’t have account at git.sailfishos.org…

1 Like
#50

You can ask @lbt on IRC (#mer or #sailfishos on Freenode) if you would like to have one there.

4 Likes
#51

I don’t think we have any time plan for the migration - please don’t wait for that to happen if you have patches to send.

#53

please don’t wait for that to happen if you have patches to send.

Well, in the past that did not make any difference.
In hope that this may have changed (you tend to sound so authentically enthusiastic @vige), as one example, see https://git.sailfishos.org/mer-core/udisks2 with a few issues and MRs nobody ever reacted to (I would have to look up what else I filed where).

1 Like
#54

Have you pinged the developers? It’s quite possible that no one has noticed your MRs, that happens quite easily with gitlab.

#55

@vige, no. How? Why?
Gitlab emits emails to the maintainers on every new MR or issue.

#56

The way I usually do it: Look at the git logs, see who has been making most of the commits lately. Ask them to review.

I can think of at least two reasons why this does not work in practise: 1) When you get ~50 emails daily from various git repositories, it’s quite easy to miss the actually important one. 2) There usually isn’t only one person who maintains a single repository. When there are several people doing it, it’s quite easy to think that someone else will take care of this MR.

4 Likes
#57

@vige, trying to express my point better:

  • I am beta-testing SailfishOS for 5 years now, while paying (a little) for a couple of SailfishOS-licenses.
    That is fine for me, including the fact, that SailfishOS was never stabilised to a non-Beta release, and probably never will, because that is not a requirement of Jolla’s primary and only real (i.e. substancially financing) customer.
    The take-away is: I am a (minor / lesser) customer of Jolla, paying to be a beta-tester (as all other Jolla customers with a personal license do), and accepted that long ago.
  • I reported a couple of 10 bugs to Jolla, received feedback from Jolla for less than 20% of them (usually acknowledging the bug) and less than 5% were resolved.
  • I believe I already did way more that a typical beta tester:
    In most cases I also submit some proper analysis together with the a bug report, often accompanied with an MR or at least a workaround.

Jolla obviously has or deliberately created a big structural issue here (since SailfishOS’ beginnings):
As you point out, Jolla is apparently deaf for bugs reported over conventional channels, which exist for this very purpose: reporting bugs.

If somebody denotes that, Jolla’s usual reaction is to single-out that person and issue, by requesting to jump to further hoops:

  • “Please bring it up at the open IRC session”
  • “Please report it to somebody personally”
  • “Please fill out our internal bug-tracker form (in addition to an extant bug report)”
  • etc.

Jolla is systematically and consistently shrugging people off by this mindset and course of actions.
Still new people (like you) sailors are usually replicating this behaviour right from their start at Jolla, so it looks like they are internally primed to act so.

One only wonders, what the purpose of Jolla’s public beta programme (“Sailfish X”) really is, if not testing and gathering feedback?

P.S.: I once modelled, that our testing and reporting is used by Jolla for enhancing SailfishOS to become more appealing for big licensees, but Jolla never seems to have utilised it this way.

Fact is, that Jolla deliberately leaves many resources and much energy untapped, due to this very non-integrative testing and development process.

P.P.S.: @vige, while rereading your reply for a third time, I realise, that your central statement is: “Jolla has (developed) no working processes for bug reports and MRs, yet.”
While this understanding may be the basis for designing a change for the better (after more than 7 years, but “better late than never”), you really do not sound like this is ever going to happen (rather the opposite).

4 Likes
#58

if you know the maintainer, the most efficient way to notify him/her is to @ message.