Things that would need to happen to rename syncthing to pulse

Development
1

This is a list of things that need to happen for the actual syncthing program to be renamed. All of these need to be taken care of by someone. This is all from the top of my head, and I might have forgotten stuff. The page is wiki, please add whatever I’ve forgotten. (cc/ @AudriusButkevicius, @aral)

Assumptions

  • This will happen in a new “major” release, i.e. “Pulse v0.11.0” unless we reach a higher number first.

Internal things we need to do

  • GUI
    • Logo and text. Trivial, just hack index.html and rebuild.
  • Binary rename:
    • Build scripts, s/syncthing/pulse/ everywhere.
    • Jenkins, build and test configurations
    • Release signing and upgrade scripts
    • Upgrade code, looks for syncthing binary. Need to handle compatibility with older versions, somehow? Or not, require manual update? If so, the upgrade location (i.e. github releases) should probably not remain the same, as old versions will try to upgrade and then fail.
  • Config directory
    • Needs to be moved, with a controlled migration. We’ve done this before…
  • Source
    • Import paths, variable names (?), log texts, etc. Requires coordinating a move of the repo, if one is going to happen.
  • Upgrade server location, depends on what happens with github repo. Move to a new place?
  • Discovery server; no problem, just change the default and use a cname.
  • README
  • Usage reporting server. Currently connected to by IP to work around lack of DNS resolution on Android. Could keep and just point a new name towards if we like, or move and accept loss of reports from older versions.
  • .stignore and .stfolder files may need to be renamed, at some point.

External impacted stuff

  • Each and every packaging (Ubuntu, homebrew, Android, FreeNAS, etc etc). Someone needs to figure out which these are and coordinate with all the corresponding people. (https://forum.syncthing.net/t/community-contributions/611 is a good start but probably not up to date)
  • Dependent packages, like syncthing-cli, the discosrv etc.
  • Anything else that reads the config or otherwise depends on our file layout?

Undecided

All in all it’s a lot of work and a lot of people affected; we should be careful to take stock of that in advance as much as possible.

2

Regarding the discovery server, setting one up appears to me to be a case of spinning up a box somewhere, downloading the linux build of the discovery server and setting up an upstart script to start the discovery server as a daemon when the os restarts. (as well as all the usual stuff like sane ssh settings and so on) If it is actually more complex than that, or if there are options to make it more robust, such as support for failover and such like it would be very good to know.

I’ve been through this thread Own Global Announce Server? and experimented by setting up a small cluster of syncthing clients + a discovery server and that seemed to be all there was to it but I’m wondering if there are any undocumented options I should be using or anything else it would be helpful to know.

3

That’s all there is to it! (Lets keep this thread for discussion actually related to the above, though)

4

Yes, I wasn’t asking in a general sense but under the assumption that the main global discovery server would be migrated over to one managed by ind.ie at some point. Apologies if that wasn’t clear :smiley:

1 Like
5

So, now I recognise you. Sorry about that. :slight_smile: For the record, the current official server runs it like this:

/usr/local/bin/discosrv-v0.9 -limit-avg=4 -limit-burst=50 -limit-cache=10000 -stats-intv 300 -timestamp=false

The rate limits are somewhat increased from the defaults and the binary renamed because there’s also a v0.8 version running; that one should probably be shut down at this point, people should get with the times and update… It uses 18 MB of RAM and 0% CPU, so it’s quite lightweight. The db on disk is about 2 MB.

6

Perfect. Thanks for the additional info

7

.stSOMETHING files might need renaming too.

1 Like
8

For syncthing-android, renaming would be rather straight-forward, except for the package name.

Changing that would make it a new app to Google Play and F-Droid, so every single user would have to install the app again. And we can’t access the old installation’s data to copy it over, so you’d have to install it again.

Edit: What I’m saying is that I would definitely keep the package name in my case.

1 Like
9

That might be strange for some users, if there are different names in the app GUI and the web GUI.

10

asd[quote=“calmh, post:1, topic:1131”] Should the github repo move? If so, to what? [/quote]

The guy at https://github.com/pulse does not seem to be very active. Maybe someone could talk to him?

1 Like
11

The package name is only visible in the code (and Google Play/F-Droid URLs). So it shouldn’t really be noticeable for users.

12

I could rename the PPA and/or the package.

If I renamed the PPA, the users would have to change their software sources.

If I renamed the package, I could just add a new one (leaving the users on their own) or change the old one to depend on the new one. This would ensure an unproblematic update.

I think, I’ll do this in the same way as @calmh on GitHub (including the automatic updates).

13

I think I i misunderstood what a package name is. Thank you, now its clear. :smile: