TODO


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
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

TODO
====

euscan
------

### Version detections

- Check other distros (youri, distrowatch, distromatch, whoas; Equivalent-Packages)
- Steal ideas from other tools (uscan, portscout)
- Steal data from other tools (dehs)

### Command line interface

- html output

### Tests

- Write tests for handlers
- List some packages to test specific handlers
-- Sourceforge: mummer, bfast, vcftools, mtop, phppgadmin, e2fsprog-libs
-- Berlios: nast, enigma, usbprog, python-wifi, wifi-radar, bcm43xx-fwcutter
-- Google code: pychess, redis, rssguard, ostinato, pidgin-facebookchat

### metadata.xml

- Use handler's statistics page to generate metadata for some packages
  (handled by deb or brute force for example)
- Create a subtree of metadata using custom rules
- Finalize format
- Write a GLEP
- Convert subtree
- Commit metadata.xml changes to tree

### packages:
- MySQL: should use http://downloads.mysql.com/archives/
- mariadb: should use http://downloads.askmonty.org/MariaDB/+releases/


### handlers

- remote-id type deb repository:
-- find out how to get download url (not sure it's possible)

### remote-id
- Propose new remote-id: deb
  e.g.: <remote-id type="deb">
            http://mysite.com/deb/dists/stable/main/binary-i386/Packages
        </remote-id>
- Propose new remote-id: freecode
  e.g.: <remote-id type="freecode">projectname</remote-id>


euscanwww
---------

### misc

- Really fix mails: better formating
- Always keep in db all found versions (when using an API only?). But don't display them if older than current packaged version, except maybe in the "upstream_version" column.

### packages

- show additional informations in the web interface (remote-id, etc...)
- Ignore alpha/beta if current is not alpha/beta: per-package setting using metadata.xml ?
- ~arch / stable support: see "models: keywords"
- stabilisation candidates: check stabilizations rules, and see how this can be automated
- set upstream version by hand: will be done after uscan compatiblity

### logs

- Move log models into djeuscanhistory ?

### models

- Repository (added or not, from layman + repositories.xml)
- Arches and Keyword
- Metadata, herds, maintainers and homepage are per-version, not per package. Store it in Version instead.

### djportage (LOW-PRIORITY))

- Create standalone application to scan and represent portage trees in models using work done in:
-- euscan
-- p.g.o: https://github.com/bacher09/gentoo-packages
-- gentoostats: https://github.com/gg7/gentoostats_server/blob/master/gentoostats/stats/models.py

The application should be easy to use, and we should be able to launch the scan process in a celery worker using "logging" for logs.
The application should also be usable for p.g.o and gentoostats later...
The scan process should be faster than the one using euscan. gentoo-packages have some interesting ideas for that (keeping metadata and ebuild hash, etc..)

### API (LOW-PRIORITY)

- Move to tastypie

### Overlays

/!\ blocked by "djportage" application
Currently, overlay handling in euscan sucks (it's simply a column nothing more, and they are mostly handled by hand by layman). I'd like to be able to add and remove overlays (overlay name + svn/git/cvs/rsync url). Using a new model and layman API should make this task easy.

/!\ could be done earlier using a simple "overlay" table ... but how to pre-compute everything per-overlay ?
Once done, a great feature would be to be able to select displayed overlay on euscan (as a global setting: for all pages). This is actually a lot of work, so you should work on that on a separated branch.

Note that this is more complicated that it seems, because a lot of things are precalculated (number of version for this herd, number of outdated versions, etc..), and selecting overlays would break all this. So you'll really need to experiment solutions for this one.