@martinheidegger , I wanted to prepare the test archives for this issue dat-land/dat-desktop#559 in a Github repository. They would be then deployed on a couple of peer nodes.
Now I'm asking myself, if it's a good idea to include a
Now I'm asking myself, if it's a good idea to include a
.dat directory into the Git repositories. If I don't do this and run git init on the first peer, it will use the metadata from dat.json, but it will generate a new URL. But does .dat contain data, that I better don't make public, even for this use case?
They should be somewhere else.
The .dat folder contains the public key etc.
You need to add it.
too busy schedule
As far as I remember, with AppVeyor settings can be redundant sometimes: what you can configure in settings can be also configured in their web interface.
@dkastl can you give https://github.com/dat-land/dat-desktop/tree/add/linux-icon a try to see if it adds an icon to linux?
Reading through the WIKI: https://github.com/dat-land/dat-desktop/wiki/UI-Components needs to be deleted or updated.
This might come in handy?!: https://github.com/dat-land/dat-desktop/wiki/Release-List
For example, like GitHub's ContributionMap (green-cells).
I just had a discussion with @AtuyL in person:
We use PR's in github in order to understand and review changes:
- If the PR exceeds a certain limit: the PR is hard to review and its hard to detect problems.
- If the PR contains multiple changes: it is hard to understand the influence that each PR has.
- If the PR is not executable & has bugs: the first assumption is that the PR has an issue that needs to be fixed.
But in @AtuyL 's case, he touches a lot of code and the PR's are dependent on each other which makes some of the effort temporary and creates quite a bit of overhead.
Right now I know of no way to reduce the effort of putting the into small chunks. Do you have an idea how we could make this simpler?
Small Update: I still find a lot bugs (almost hourly) in the middleware (and in low-level libraries) that explain some inconsistencies we have seen in the client. For that reason I started to implement more sturdy tests for the middleware that actually test the behavior we expect (including filesystem and network interoperatibility)
