Finally Sailfish Weather is out now! There are other repositories and components in the pipeline. Like discussed during community meetup at Tampere Plevna 2nd July, we’ll continue open sourcing in phases during Q3/25.
Based on phase 1, feedback and areas of interest & activity
Starting point
We’re starting from the Sailfish Weather as many of you have requested it, it used to be a really handy in the Events View and you have even changed Weather app forecast to use the OpenWeather API. Next one could be Sailfish Camera app – please share your thoughts and stay tuned . Having Sailfish Weather on Event Views would be awesome!
Thinking is that together we can do a great camera app that we’d all enjoy to use. We started a good discussion on possible other improvements in the past community IRC meetings (referring to previous forthing). Like discussed at the Tampere community meetup, we’ll adjust these based on your needs, contributions and wishes. We surely listen them.
Contribution License Agreement
With our limited resources we decided utilize the Harmony (HA-CLA-I-ANY) Version 1.0 Contribution License Agreement (CLA) similarly as we already have in use for Sailfish Documentation. The CLA will be applied on repository basis.
These packages are not available on the Community OBS, hence building there will not commence.
Will these packages be made available as well?
What is the recommended workaround if not?
One WA is to have, in the same OBS project, a dummy RPM which Provides: the mentioned package.
Using prjconf to Ignore: the dependency does not seem to work.
This opens a rather interesting question that I failed to comprehend since I’m retarded.
Uhh, does this now allow us to possibly improve upon the apps with PRs, or just make us feel better that we got them opensourced? I guess that it would be theme like with the rest of Sailfish OS stuff, but getting stuff merged into the repos sometimes takes much longer than is needed for even some of the most basic stuff.
The BuildRequires on the translations package is only for getting the version for the Requires, so it does not really affect the build it self (except that it actually causes some extra rebuilds).
What I need to check is why the versioned dependency was introduced originally, because I think it is not necessary, but there must have been some reason for it.
Dear @Morc ! One key priority is that this enables us to work together for Weather app. Secondly, I strongly feel that openess builds trust as you can go and inspect the source code. When it comes to getting stuff merged, it is greatly process related. That said, eventually we need a merithocratic system to GitHub repos where you can gain various rights such as review rights, merge rights, component owner and so on.
I had to ask especially because I feel like adding a feature or two to the Notes app (if not even some others like the Weather app?) and actually not having to reimplement it in a custom app from scratch would make it cooler from the OS/community standpoint where the particular features could be in the system app directly, it could be obviously nice because that would actually improve the experience for everyone else and it could especially feel cool for us contributors since we can actually get the chance to pitch in with our own things without needing to rely on the aforementioned custom apps or kinda helplessly wait for Jolla with their “limited R&D” with which you obviously can’t always fulfill everyone’s requests. Thanks again for the clarification!
p.s. btw, sorry for the harsh tone of my former message… Oops .
Is the process already defined? Being worked on? Documented (and published)?
Sorry if this sounds a bit annoying, but I’m very interested what the requirements/expectations here might be.
Also, publishing that will help potential contributers to know what precisely to do work on, and not to waste time with things that are not going to be accepted.
Also: can we help coming up with a good process in some way? There’s precedent of the community coming up with something like that: the Bug Coordination effort worked well (for a time) for example.
Yes @nephros it’s defined. You have a very valid question – I’m not taking this personally at all, don’t worry. It’s our internal policy but we likely need to be loosen that a bit without loosing code quality. I wouldn’t lay down the policy yet. Let’s see how everything starts rolling.
These are great news! Thank you Jolla to open yourself after such a long time. It feels like we are now charting a course for a more transparent and collaborative horizon