-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO.txt
68 lines (47 loc) · 1.67 KB
/
TODO.txt
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
59
60
61
62
63
64
65
66
67
68
---+ Thoughts and issues
---++ Port
* Avoid the need for links by creating a file that loads the real
file:
:- module(win_link_<orig_module>, []).
:- reexport(<path-to-orig-module).
---++ Wishlist
* Allow owner/user to overrule problems (notably undefined
predicates).
* Enhance author interface for updating packages.
* Removing packages. Notably, we need to keep track of the
config files, so that we can delete them. We can base that
on config.done, which keeps track of where the file comes
from.
* Removing packages: warn about broken dependencies. This
probably needs a list of why a package is installed: one
of
- explicit
- resolves_for(<pack>)
* Signing. Also make servers sign versions
* Allow users to trust each other and/or allow them to
give other users the right to update a repository.
---++ Git versioning issues
Currently, the cpack-mirror is a _mirror_ repo from the author's
repository. This means that a 'git fetch' in the cpack server updates
all heads forcefully to the author's version. There are a number of
scenarios that require attention:
---+++ The author submitted a broken version
One possible solution is to add a tag after we do a pull. This would
allow us to step back using:
==
git branch -f master <tag>
==
An alternative is to have a branch =cpack=, which is updated to the
desired branch or tag after the author analysed the consistency of the
target point.
---+++ Dealing with local changes for users
Current approach does
==
git fetch
git merge origin/master
==
---++ Long term:
* Rating system
* Trust model
- By reputation
- By code analysis