Simon Frei

Another way to break dependency cycles is to move types into a sub-package, e.g. `lib/model/types`. If we go the "all types in events" route (which then also means `FolderCompletion` and...

1. A simple solution is adding an interface for`*db.FileSet` in config, something like ```golang interface MtimeOptionBuilder { MtimeOption() fs.Option } ``` Alternatively refactor `fs.NewFilestem` to a builder type, and make...

While I like not pulling in unnecessary dependencies, handling time and its localization is hardly something we should do ourselves. That's both a universal and not at all trivial problem...

I had a rough look at the Go part and first impression: It's a lot of code for a bit of usability. I do think (or at least hope) that...

Thanks for your patience waiting for my reaction. I do agree we should talk about API/UX primarily, otherwise we might use time for implementation aspects that then don't get used/need...

As usual, nothing wrong with the arguments you make. However the beneifts (nicer api, future more helpful UI dialogs) still do not justify the current complexity for me. One trade-off...

I was trying to express the following before, but held off because @calmh brought up a concrete alternative approach. Now we are again in a similar spot, so here it...

Up front because I think that gets lost and I can drop some "I thinks", "subjectively", ...: Again, it's not about right or wrong objectively, it's about what I want...

The bad but still correct answer here is: Don't have introducer cycles: > It is not a good idea to set two devices as introducers to each other. While this...

Yeah right, wasn't such a nice move to unilaterelly repurpose your ticket - reverted that, and created #8393 for the warning. My opinion is that it's not worth investing the...