1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
== Introduction ==
This repository is meant to store various data.
For instance devices have various partition tables such as the PIT and GPT
tables and as it is binary data, it could be interesting to have various PIT
and GPT stored somewhere.
However as there is already data in various other projects, it would make sense
to only have data that is not already covered by other data projects.
So for instance we could store all the PITs for all the smartphones that do
exist, even if they are not supported by Replicant. However we don't want to
store Type Allocation Codes (TAC) data here as there is already a project
under a free software license for doing that, and it is easy enough to
contribute to it.
Here are various places to contribute data to:
- Replicant website:
Website URL: https://www.replicant.us
Repository URL: git.replicant.us/replicant/website.git
Data: supported devices list, freedom/privacy/security article, FAQ, etc
- Replicant Wiki and other sub-wikis:
Website URL: https://redmine.replicant.us/projects/replicant/wiki/
Data: User and contributors documentation, information on devices, research
etc.
- Wikidata:
Website: https://wikidata.org
Data: Has information about Replicant versions, libsamsung-ipc, various
devices supported by Replicant, etc.
- Osmocom TAC database:
Website: http://tacdb.osmocom.org
Data: Collects Type Allocation Codes which is made up by the first 8 digits
of the IMEI.
- Osmocom terminal profile database:
Website: https://terminal-profile.osmocom.org/
Data: Collects terminal profile data which is a standardized way of telling to
the SIM card what it is allowed to do (redirect calls, etc).
== Version control ==
Git is not optimized for handling files: instead its data model is based on the
notion of content (like the content of a file) regardless of where that content
of data is stored. This is data model is way more efficient for source code as
people are usually more interested in the diff, in rebasing, etc than merely the
file path itself.
In contrast a distributed version control system like Mercurial uses a different
architecture which is based on files instead, so in theory it should be way more
efficient than git for binary files.
However as the current Replicant infrastructure wasn't tested with other version
control system than git and that most Replicant contributors are already used
to git. According to the official book on Mercurial[1], switching from git to
mercurial looks very easy, but it doesn't tell how well it does the
conversion.
References:
-----------
[1]https://book.mercurial-scm.org/read/intro.html#switching-from-another-tool-to-mercurial
|
