I see a lot of work being done in the syncthing-fork repo with an active release schedule. The standard app has not received an update since November.
I’m just wondering if it makes sense to switch to the fork.
We have no contributors to the main app, and the maintainer of the fork was not a fan having to address review comments or going through reviews in general, hence decided to fork.
I don’t think the fork gets any reviews or scrutiny, so sure, it is actively released and maintained, yet we take no resposibilty of whats in the fork.
1 Like
The maintainer of the fork, namely @Catfriend1, has interest to bring his changes into the app (and has done so recently), in addition @capi did a (multiple?) PRs lately and you fixed a build issue lately. There’s not much development going on, but more than none 
Personally I’d like to see the android app being released along with Syncthing. I.e. new release whenever Syncthing is released, and if there is such a thing as beta/RC releases on android, also if an RC for Syncthing is released. I do have some time at the moment, so I’d be interested in being explained how the release process works and taking that on if that’s welcome.
4 Likes
I find it very unfortunate that there has been such high incompatibility between the official repo maintainers and @Catfriend1’s approach to coding. I do understand that the offical maintainers of the Android fork, and especially the original creator (@Nutomic), want the project to be continued in their preferred style. BUT, I think that any improvement over the current de-facto standstill would be preferable.
Thanks for the mention @capi, I dont follow the forum any more. I am doing other things now (like hosting a Peertube instance), so I dont have the time or motivation for Android programming any more.
I dont have any problem with @Catfriend1 maintaining the app, and I dont think it makes sense that we have two different apps.
I wholeheartedly agree! Fragmentation because of differing views is one of the big problems in OSS projects. I think it would be a huge win for the Android users if @Catfriend1 could continue @Nutomic work.
I think it has been clearly established that it would be nicer if all the progress happens in one place. There’s no disagreement with @Catfriend1 anymore on contributions, however it’s not so easy to backport stuff at this point (fork has diverged). My point is unrelated to this - it’s about releases, which are not happening at the moment.
I am not actively following the fork, I have a pretty old self-compiled version which does everything I want it to do. A valid backport strategy could be to simply replace the current version (via a merge with git merge -X theirs) with the one of the fork and go from there.
My own little PR always took way longer than originally intended (and were a little bit frustrating, to be honest) due to the feedback in the PRs, but they always ended up better code quality this way. Maybe a sensible middle ground could be found. I do think that there should be reviews, but sometimes moving ahead might be better than the perfect solution to every last detail. But this is for another discussion.
1 Like
Perhaps we kill the main app and let people use the fork without the old app getting in the way.
I don’t, however, want to endorse anything under the official umbrella if reviews are not an option and are a point of furstration.
Next thing we know, peoples phones are mining bitcoins because the code went in under no scrutiny just for the sake of moving the code forward, and we are collectively held resposible, destroying reputation of the tool and the things we stand for.
7 Likes
Code reviews are just something you learn to suck up. Yes it’s annoying when someone asks for insignificant changes, but they don’t take long to action, and ultimately the end result is better…
My opinion is that we shouldn’t be compromising on quality here.
5 Likes
I never said anything about not doing code-reviews. I just said, that sometimes you don’t need to discuss every naming of a variable.
Very honestly, the current version does everything I need, so for me personally there is no need for further improvement besides making sure that it works with the latest version of Syncthing on my desktop and on the Android version I’m using.
Regarding the release cycle, there have been changes to master in the official repository (namely my PR), what is the condition for this to getting released to Play?
@Nutomic Would it be possible to transfer the permissions needed to deploy the “Syncthing” app via the Google Play store to @Catfriend1 ? It has a lot of users which won’t receive new updates if the deployment channel changes.
There are multiple aspects here. I don’t take a too active role on the Android side, but for what it’s worth these are my opinions;
-
There should be a regular, predictable release schedule. Users should be able to know what to expect and when, contributors should know that their contributions will make it out there and when. The details are of course up to however maintains it, but something like a monthly release cycle of beta + stable somewhat synced with Syncthing-core would probably not be a bad start.
-
There were some mis-steps and personality conflicts. Neither @Catfriend1 nor @AudriusButkevicius seem to be shining beacons of low key diplomacy, and also weren’t in sync on how to do things. I think some attitude adjustment in both directions are possible, and possibly have been made. Future cooperation here shouldn’t be impossible.
-
The project is indeed @Nutomic’s baby and he would certainly be able to wield some influence over who should continue maintainership and releases. It is not, however, simply a matter of who wants to write code for it today. Maintainership is about maintaining other people’s code, possibly for years and without any more thanks than what’s given in this thread. Change is also disruptive. All this means that some care should be taken when signing over things.
imho etc
9 Likes
I would be very much against this as this undermines all the things I suggested above. If you don’t want code reviews, sadly I think it should be a separate project like it is now. I don’t however oppose the idea of delisting the android app and letting the fork be the prime app.
1 Like
I do oppose the idea of de-listing, since there are a huge number of users out there. I think the goal should be to get the fork to be re-integrated and/or replacing the current offical repo. I don’t/didn’t have the impression that anyone was rejecting the idea of PR and that reviews are important. I wouldn’t want to diverge from it. But I do think that a reviewer could also accept code more easily if it moves the progress forward, even though the code does not fit 100% the taste of the reviewer.
Especially if there is an eager contributor and the creator stated that he doesn’t have time/resources/interest in further maintaining it, so the argument that the code has to be maintained by other people “forever” does not really count in my opinion. @Catfriend1 is willing to more or less take over. I also was under the impression that he did not object having to go through PR and review, but that the constant “this needs to be better; that should be changed; that does not meet our taste” drove him away.
Again, as I said above, for my miniscule contributions, it was a bit frustrating, but YES, it did end in a way better solution. But did it also reduce my enthusiasm for contributing other things: yes, as well. So maybe we all can find a better way of interacting.
@capi You said it better than I could. It would be a bad idea to discontinue the official app. And @Catfriend1 has been putting in good work, and I think it makes sense that he maintains the official app. I haven’t closely followed the development for a while, so I’m not sure about the details of the fork. Reviewing for security isses is great, but if there was nitpicking about variable names, I could understand the frustration (I dont know which one it was).
Anyway I hope @AudriusButkevicius and @Catfriend1 can find some kind of compromise. Maybe less strict reviews, but doing a beta release before releasing a proper version.
1 Like
Comments from a passive observer here. I’ve been following the syncthing-android repo for quite some time and saw the involvement and departure of @Catfriend1 and the discussion with @AudriusButkevicius. So first of all, you both do get a big Thank You from my side for all your efforts.
I think we agree that compromising quality is no good option and that getting through critical reviews improves the end result, even if tedious. One learns from those remarks and they will get fewer.
One fundamental difference in thinking I noticed in those discussions was the approach to functional verification. Respect to @Catfriend1 for diligently smoke testing each revision and doing lots of “human GUI fuzzing”. I can totally understand the frustration when requested changes block the merge but would basically invalidate all that testing again.
Having said that, I personally err on the side of understanding code well enough that one can be certain it does what it’s supposed to. Just because I’ve seen it working under all circumstances imaginable does not mean it’s fool-proof. Proven code catches all corner cases because every detail has been thought about, not by trying very hard to repeatedly find more problems by accident. I think that’s the direction @AudriusButkevicius was steering toward. It might have got a little lost because of his rather direct and terse communication style.
So no, I didn’t perceive it as nitpicking about variable names, but a different way of thinking about code correctness. Hopefully this independent perspective may help all those involved to get along and avoid conflicts by better mutual understanding.
Thanks again for your work on this, team. I see great potential and am looking forward to a much improved Android wrapper. 
2 Likes
So, I’m going to latch on to this and propose it as the practical way forward. Making a new release should be as simple as tagging and pushing a button, maybe running some script. Syncthing releases on the first Tuesday on every month, predictably. I can push the tag already on Monday so that there’s time to incorporate it into whatever the process is. @imsodin if you don’t figure it out or need credentials / build server assistance, let me know.
Fully agreed. Reviews and changes to patches before they are accepted is the way things work in our corner of open source, at least. A given patch might work fine and be battle tested by many users, and still require changes to fit into the way a project is being maintained.
1 Like
Would it be possible to split the app? The bare minimum(wrapper+syncthing binary) could be provided as part of the syncthing project. The UI could be delivered in a separate app.
Edit: or maybe publish it as an Android library?
Wrapper is the UI