Are some /e/ Apps obsolete forks?

Hey. I want to preface this by saying that I’m not out to spread FUD about /e/ - I know the project is still in extremely early beta and working on getting off the ground.

I noticed this bug report, about the Calendar app and the linked comment by the Etar dev, which seemed to suggest that the Calendar app is running on top of very old Etar code.
I was a bit confused by that as my understanding was that the /e/ Apps were in essence ‘downstream’ from their parent projects and were kept in sync with upstream, but now I’m wondering if they are actually hard forks.

Basically, I want to know:

  1. Are there any procedures in place for continuously refreshing the source code for the /e/ Apps from upstream? (Etar for the Calendar app, OpenTasks for the Tasks app, Bromite for the Browser app, etc. etc.) If so, how often is that done? If not, are these apps hard forks? Who is in charge of maintaining them?
  2. Is there anywhere that these things are documented? I think from a security point of view it makes sense to be transparent about how it’s handled :slight_smile:

Again: I don’t want this to come off as nitpicky. I just want to know whether the apps are considered ‘downstream’ or considered their own things, and what development duties lie where.

2 Likes

The default apps like mail and calendar are forked but not updated automatically. An automatic upgrade of code will not work as they have been customized to run on /e/. An automatic upgrade will most probably break the existing customized code.
You can raise a bug if not already done to have calendar upgraded to the latest code base.
You can browse individual apps on gitlab to check the source code …for e.g. for calendar the code is available here

For me, some the /e/ apps don’t add any value compared to the alternatives, so I don’t use them.

For email I use the upstream K-9 Mail which - in my view - handles multiple accounts better (by displaying different colour indicators for different accounts in Unified Inbox.

  • For Calendar and Contacts I use Simple Calendar Pro and SImple Contacts from F-Droid
  • I use F-Droid or Aurora Store for app management
  • I use OpenLauncher or Lawnchair for my launcher / home screen, as I prefer the ‘traditional’ Android experience rather than the ‘imititation of iOS’ which is Bliss Launcher.

That’s the great joy of Android for me: if you don’t like the way your chosen ROM does things, then you can always find something that does it ‘better’!

Thanks for replying. Although I don’t understand this part. Why should I - a regular user - keep track of the upstream changes and report to the /e/ team whenever it’s time to refresh? I thought /e/ was aimed at non-tech users. Shouldn’t merging of upstream changes be coordinated in a more appropriate place, like in the dev team?

1 Like

Methinks they do it this way. Many devs appear to use e as daily driver. The camera app was updated recently for example.
It is a complicated matter. For example in Linux distribution its like Debian stable vs. experimental. With e you are on a stable brach, that might seem old and might cotain bugs. But keep in mind latest software contains bug too. This means potentially more distracting bugs reports (‘‘is the bug due to e or due to the software?’’) for e. Being an developer myself, I can understand the approach by e.

1 Like

Non-tech users don’t care at all about this (totally legitimate) concern of yours, as long as the forked Apps do their job. So non-tech users don’t need to keep track of upstream code, so there’s no issue in that regard.

Who says that it isn’t?
I think @Manoj just wanted to point out the established way to get in touch with the developers to get this resolved or clarified.

2 Likes

The bug report that I linked in the OP seems to indicate that at least the Calendar app runs on pre-2018 source code from the Etar Calendar. What about the potential security fixes that the Etar Calendar has had since then? That would seem to suggest that the /e/ Calendar app is still vulnerable to those. (in fairness, since I don’t know if there has been any security vulnerabilities in the Etar app since 2018, this is more of a theoretical scenario)

Coming from the Linux world myself, one of the biggest issues with constant forking and derivative projects and distros is that many of them end up with small dev teams and thus being poorly maintained compared to upstream, ultimately leaving their end users vulnerable. I’m just wondering if /e/ is at risk of the same tendency.

1 Like

Alright, just to get some concrete data into this discussion, I went and compared version numbers of the forked apps currently on my /e/ FP3+ with the version release dates of the upstream projects, and this is what each of the current /e/ apps correspond to:

/e/ Browser: Bromite 83.0.4103.93 (released in June of 2020 with many updates to Bromite since then)
/e/ Calendar: Etar Calendar 1.0.21 (released in February 2020 with a couple of updates to Etar since then)
/e/ Tasks: OpenTasks 1.2.3 (released in October 2019 with a single update to OpenTasks since then)
/e/ Messages: QKSMS 3.7.10 (released in December 2020 with a couple of updates to QKSMS since then)
/e/ Camera: OpenCamera 1.48.1 (released in May 2020 with a couple of updates to OpenCamera since then)

All in all the difference is not as huge as I had feared. Although I still would like the dev team to explain - here or somewhere else - how often they refresh the source code from upstream (and if there even IS an upstream).

2 Likes

The pointer from @Manoj still applies. The /e/ GitLab is the place where the developers are and where you can raise an issue to discuss it with them.

Also
K-9 Mail v5.722, /e/ Mail v5.600.

The way I read @Manoj 's pointer was that you could raise an issue to request to have the codebase updated, not to have a discussion about how often codebases are typically refreshed from upstream. In fact, I’m fairly sure that’s exactly what this forum is for.

Have it your way, nobody forces you to go the direct way to get this sorted out :wink: .