As I just laid out in an issue report on the fork's issue tracker, it is currently very confusing as an end user (and/or potential contributor) where to start with the Android client side of things. It does seem like there was a time the upstream had stalled and a fork successfully pushed things forward, but looking at the more recent history that does not seem to be the case any more and the resulting dual-development and release channels have created a confusing situation. All the documentation I could find on the fork situation is also somewhat dated.
I've been around the open source world long enough to understand there are (at least) two sides to every story and often we have to make do with less than ideal development practices. That being said I think it would be useful for this upstream project to comment on the same issues.
What is the status of development on this project vs. the fork? Is there any desire to see the features and fixes developed for the fork contributed here to the upstream project? Is so what is the barrier to that happening? If not, why?
What is the hoped for pace of development on this project going forward?
Where should potential contributors focus their efforts and why?
Thank you.
There are no active developers in this project. We accept community contribution and do minimal maintenance to keep things going, but that's about it.
I guess all the features that are upstream we'd love to see here, but there is simply two diverging ways the project owners want to work. Here, we want code to be reviewed, scrutinized, potentially improved by the review process, potentially ask for automated tests.
The fork happened because the fork author wants to "move fast". That means there was dissatisfaction when we reviewed the code, challanged decisions, asked for changes or automated tests. The fork happened because the author doesn't want any of those software engineering practices getting in their way which makes moving fast harder.
Potential contributors can choose to contribute their time where they see it best fit. If you are a fork user as you value features over integrity, I guess it makes sense for you to contribute to the fork. If you prefer to use something that has hopefully gone through eyes of atleast a few people, I guess it would make sense to stick to the original project.
And just to be clear, I am not dissing the fork, I think a lot of awesome work happened there that keeps users from abandoning syncthing in general as the original app is clearly inferior. It's a great loss that the fork happened and I wish that was not the case, but we cannot accept unsolicited development as we deal with peoples data, advertise being security and privacy focused, and as minimum reviews is a thing we need to maintain those claims.
So we have got put infos on both trackers (issues) and I guess you are okay closing the discussion?
Actually I think there is a bit more to say, out it's the weekend and I need time to consider. I don't think the discussion should be closed too hastily.
October 22nd: I still have this tab open ;-)
December 27th: Still...
This repo has much less info in the readme than the fork, but the situation seems to have changed - is this app well maintained again? Has it "caught up"? The situation is indeed confusing.
Audrius' comments above still apply.
Currently I take care of releasing syncthing-android in-sync with syncthing releases (barring delays due to google play publication issues). I also do small (minimal) changes to keep the app working/compliant/useful as android changes. And there's the very rare drive-by contribution.
Most helpful comment
There are no active developers in this project. We accept community contribution and do minimal maintenance to keep things going, but that's about it.
I guess all the features that are upstream we'd love to see here, but there is simply two diverging ways the project owners want to work. Here, we want code to be reviewed, scrutinized, potentially improved by the review process, potentially ask for automated tests.
The fork happened because the fork author wants to "move fast". That means there was dissatisfaction when we reviewed the code, challanged decisions, asked for changes or automated tests. The fork happened because the author doesn't want any of those software engineering practices getting in their way which makes moving fast harder.
Potential contributors can choose to contribute their time where they see it best fit. If you are a fork user as you value features over integrity, I guess it makes sense for you to contribute to the fork. If you prefer to use something that has hopefully gone through eyes of atleast a few people, I guess it would make sense to stick to the original project.