Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
137 lines
4.4 KiB
Text
137 lines
4.4 KiB
Text
Design Process : Development Framework
|
|
======================================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2007-06-08_
|
|
|*Proposed by* | ct
|
|
|====================================
|
|
|
|
|
|
|
|
|
|
Development Framework
|
|
---------------------
|
|
Here we collect how the tree/repository will be set up and which tools are
|
|
needed/required for working on lumiera.
|
|
|
|
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
.Tools required:
|
|
* Unix like shell environment with standard tools
|
|
* we don't require a specific linux distribution
|
|
* Git 1.5.3 (not out yet, but really soon, we want submodules support)
|
|
* GNU toolchain, autoconf/automake (maybe SCons or something else?)
|
|
* Bouml (version case unresolved)
|
|
|
|
.Tools suggested:
|
|
* doxygen
|
|
|
|
|
|
|
|
|
|
Tasks
|
|
^^^^^
|
|
* cehteh will setup a initial repository
|
|
(see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure])
|
|
* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will
|
|
add backport packages there if necessary so the debian-people can stay near
|
|
Etch/stable in the next time
|
|
* ichthyo volunteers to get the new source into a debian package structure from
|
|
start (same as the current cinelerra is)
|
|
|
|
.And for later:
|
|
* decide on a Unit Test framework
|
|
(see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests])
|
|
* can we get some continuous integration running somewhere (nightly builds,
|
|
testsuite)?
|
|
* find a viable toolchain for writing more formal documentation.
|
|
ReStructured Text, Docbook etc?
|
|
|
|
|
|
|
|
|
|
Cons
|
|
^^^^
|
|
* Git submodules are just not usable yet; we need to come along with one
|
|
monolitic large project until they are available.
|
|
|
|
|
|
Alternatives
|
|
^^^^^^^^^^^^
|
|
* use visual studio and .NET [big]#😇#
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
The project will be tied to a distributed infrastructure based on Git. With recent
|
|
Git submodules support it should be easy to let contributors only checkpout/work on
|
|
parts of the tree (plugins, documentation, i18n, ...). We want to build up a
|
|
set of maintenance scripts in an `./admin` directory.
|
|
|
|
At the moment we go for rather bleeding edge tools, because we want to stay at
|
|
a given version to avoid incompatibility problems. Later on a version switch
|
|
needs agreement/notification by all devs.
|
|
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
I am always in favor of getting the basic project organization and all
|
|
scripting up and running very early in a project. I would like if the project
|
|
would take a rather conservative approach on the required Libs and Tools, so
|
|
that finally, when we get into a beta state, we can run/compile on the major
|
|
distros without too much pain. I wouldn't completely abandon the idea to target
|
|
*bsd and osX as well later on.
|
|
|
|
I would propose to move Doxygen to ``required''. The Idea to use SCons sounds
|
|
quite appealing to me at the moment. Besides that, I think this RfC could be
|
|
moved to ``Draft''.
|
|
|
|
Ichthyostega:: '2007-06-17T00:18:40Z'
|
|
|
|
Moved to Draft. For Developer documentation I would prefer doxygen. For user
|
|
documentation we can make a similar/same think like nicolasm did for
|
|
cinelerra2, means wiki for edits, git to maintain it, based on gnu texinfo.
|
|
Texinfo is quite limiting in its capabilities but it suffices, seeing the
|
|
current cin2 docs, i say its rather well done.
|
|
|
|
We need to factor out some of the proposals from this page to subpages (scons,
|
|
documentation, testing,...)
|
|
|
|
ct:: '2007-06-17T17:27:59Z'
|
|
|
|
It would really suck if we have to go through the experiences described in the article
|
|
https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«].
|
|
I have experienced parts of that
|
|
in the past. I have only some beginner experience with writing autotoolized
|
|
projects (mostly based on trial-and-error) and no experience in any other build
|
|
system (such as scons). As such, I still believe that autotools can be
|
|
manageable (for me personally) once the initial hurdle of learning is overcome.
|
|
|
|
I all for Doxygen documentation. Related to documentation are
|
|
http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking].
|
|
See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)].
|
|
I suggest
|
|
that we consider using such a tool for QA. Like ct said, this should be
|
|
discussed in a subpage.
|
|
|
|
I agree with using currently bleeding-edge tools.
|
|
|
|
* _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct)
|
|
|
|
|
|
We have now a ``compatibility wiki'', finalized this proposal
|
|
|
|
ct:: '2008-03-26T13:43:26Z'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|