#280: Get rid of trash directories
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: cleanup |
----------------------+------------------------
I.e.:
* source:milena/doc/examples/trash
* source:milena/trash
Rationale: if their content is not distributed, they should not be part of
`master`. We can style reintegrate them later from the repository's
history if needed.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/280>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#221: Post-Olena 1.0 cleanup
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
As a memo, an unordered list of miscellaneous tasks (split/reorder if
needed):
* Rename directories `{milena,scribo}/tests/unit_test` as
`{milena,scribo}/tests/unit-tests`.
* Move `milena/tests/tools/*` into `build-aux/`.
* Write a developer Manual (see Vaucanson's).
* All LaTeX-based documents (including the tutorial) should be compiled
with `texi2dvi`.
* The test `tests/io/pgm/pgm.cc` is too long (edit: check that again);
simplify it?
* More generally, we should time tests to see which ones are the most
time-consuming, both at compile- (if applicable) and run-time.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/221>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#279: Write a developer manual
----------------------+-----------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 2.1
Component: Olena | Version: 2.0
Keywords: |
----------------------+-----------------------
Task extracted from #221.
We should try to get some inspiration from Vaucanson, SPOT and maybe TC
here.
I (Roland) think `HACKING` is the right place to host this manual, as it
is the case for SPOT's (see
http://git.lrde.epita.fr/?p=spot.git;a=blob;f=HACKING). This manual
should document maintenance and development procedures, a coding style,
help on tools, good practice advice, etc. Do not hesitate to add more
ideas to this list and/or to contact me (Roland) about this.
See also:
* these tickets: #202, #203 and #258;
* these messages:
* https://lists.lrde.epita.fr/private/olena-
core/2008-September/000034.html,
* https://lists.lrde.epita.fr/private/olena-
core/2008-September/000041.html,
* https://lists.lrde.epita.fr/private/olena-
core/2009-December/000253.html,
*
http://lists.lrde.epita.fr/pipermail/olena/2013-September/000545.html.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/279>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#278: Move milena/tests/tools/* to build-aux/
-------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: trivial | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: cleanup |
-------------------------+------------------------
I believe there are other tools/generators elsewhere (including in
Scribo). It is probably a good idea to move them to `build-aux/` as well.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/278>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.