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.
244 lines
8.8 KiB
Text
244 lines
8.8 KiB
Text
2008-05-08 Lumiera Developers Meeting
|
|
======================================
|
|
:Author: cehteh
|
|
:Date: 2008-05-15
|
|
|
|
__Participants__
|
|
|
|
* cehteh
|
|
* joelholdsworth
|
|
* ichthyo
|
|
* raffa
|
|
* Wes``Lappy
|
|
* gmerlin
|
|
|
|
|
|
Boilerplate
|
|
-----------
|
|
|
|
Organization of this meeting
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
* cehteh writes the protocol
|
|
|
|
|
|
Webpage-Infrastructure, Maintenance
|
|
-----------------------------------
|
|
|
|
_Cehteh_ put this on topic because it's really urgent to bring up some
|
|
infrastructure to manage the information we produce.
|
|
|
|
The Lumiera pages on pipapo.org were always meant as intermediary
|
|
solution. Pipapo.org gets much spam on the MoinMoin wiki and _Cehteh_
|
|
expresses that he wants to move pipapo.org to a new infrastructure
|
|
based on Asciidoc and Git he created
|
|
(see [purple]#`http://git.pipapo.org/uWiki.html` <broken-URL>#).
|
|
This system is barely usable
|
|
and needs lots of work to be completed. It would be nice to use it for
|
|
Lumiera too, if the others agree. Maintaining and extending
|
|
(scripting) needs someone who knows shell scripting and doesn't need
|
|
to be done by the core devs freeing their resources to work on
|
|
Lumiera. _Cehteh_ expresses that none of the people who proposed to
|
|
help before showed up yet. WesLappy tells he might help (addendum not
|
|
this week, because he is busy).
|
|
|
|
Next there was a suggestion by _Cehteh_ to convert the TiddlyWikis to
|
|
Asciidoc. Ichthyo expresses that he likes the TiddlyWikis, Joel
|
|
mentions that they feel a little odd. Generally we all agree that
|
|
they have some problems in sense of workflow and merging.
|
|
|
|
_Ichthyo_ makes the suggestion to keep the TiddlyWikis as scrapbook and
|
|
build up ``official'' documentation based on their content in
|
|
whatever-we-use-then (Asciidoc) documentation system. All agree on
|
|
this approach.
|
|
|
|
Back to the new wiki, _Cehteh_ suggests to make stricter access rules to
|
|
prevent spam: ``There will be a group of `Validated' people which
|
|
following rules: only `Validated' people can edit general content and
|
|
`Validated' people can add new people to `Validated' themselves''. That
|
|
means that we can have a lightweight self-administrating
|
|
authentication where new people have to be introduced by someone who
|
|
is already there.
|
|
|
|
_Ichthyo_ suggests to send a reply to Serge G., who send an introduction
|
|
to the cinelerra mailing list expressing that he would like to help.
|
|
|
|
_Raffa_ will take care of content/design as much her time/knowledge permits.
|
|
|
|
|
|
Conclusion
|
|
~~~~~~~~~~
|
|
|
|
* We really need someone to help with the webpage scripting.
|
|
* Documentation needs to be well organized and moved over.
|
|
* Content of the pipapo.org MoinMoin wiki should be moved over.
|
|
* The new website should be well organized with a nice looking front page
|
|
* All other documentation should be below that
|
|
|
|
|
|
|
|
Whats pending in the DesignProcess / RfC
|
|
----------------------------------------
|
|
|
|
|
|
MistakestoAvoid
|
|
~~~~~~~~~~~~~~~
|
|
link:{rfc}_dropped/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design]
|
|
|
|
_rick_777_ wrote a "MistakestoAvoid" page which explains some possible
|
|
gotchas. We basically agree with most points there while we already
|
|
decided to address some things differently than he suggested. One
|
|
notable difference is that we do not intent to provide a windows
|
|
version of Lumiera, which was explained in several places. _Cehteh_
|
|
added some comments to the page explaining some things.
|
|
|
|
|
|
nothing more to discuss in \'Ideas', we go over to \'Drafts'
|
|
|
|
|
|
ArchitectureOverview
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
link:{rfc}/ArchitectureOverview.html[RfC: Architecture Overview]
|
|
|
|
_Cehteh_ suggests to put that drawing under version control, as .fig.
|
|
Ichthyo explains that it is already a `.SVG` and that he does not favour `.fig`.
|
|
|
|
Conclusion:: We agree to keep it as `.SVG`, add it to the repository and
|
|
improve/complete it.
|
|
|
|
|
|
GitSubmoduleTransistion
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
link:{rfc}/GitSubmoduleTransistion.html[RfC: Git Submodules]
|
|
|
|
Another suggestion made by _Cehteh_ is to make managing of subprojects
|
|
within the sourcetree easier. _Joel_ and _Ichthyo_ object that it is not
|
|
really needed now and needs more understanding of Git. _Ichthyo_
|
|
suggests that the documentation might be separated into its own Git,
|
|
he further explains that the things are not settled yet and we don't
|
|
know if we will some rearrangements and movements of files between
|
|
modules.
|
|
|
|
Conclusion:: We transform the documentation to a submodule and see how
|
|
it works. Other things will be decided much later.
|
|
|
|
|
|
|
|
|
|
GlobalInitialization
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
link:{rfc}/GlobalInitialization.html[RfC: Global Init]
|
|
|
|
This topic is discussed and agreed on the RfC page already.
|
|
|
|
Conclusion:: finalize it
|
|
|
|
|
|
MasterRepositorySetup
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
link:{rfc}/MasterRepositorySetup.html[RfC: Shared Master Repository]
|
|
|
|
Setting up an master repository was decided on the last meeting.
|
|
_Cehteh_ now set one up which also does some automatic, but intended
|
|
fragile merging from subsystem maintainer branches.
|
|
1. it updates automatically for the maintainers repo for conflict
|
|
free fast-forwards
|
|
2. it can always be overridden with explicit pushes
|
|
|
|
The others agree on the setup.
|
|
|
|
Ichthyo stresses that maintainers shall watch that their `master'
|
|
branch should compile cleanly and pass the testsuite always, test
|
|
which are not operational should be tagged as PLANNED. We all
|
|
agree, while cehteh's master is currently in a broken state (note:
|
|
fixed now).
|
|
|
|
Then a short discussion about building and synchronizing the docs
|
|
follows. Problem is that docs build in maintainer branches are
|
|
different for each branch, rsyncing them up to the server will always
|
|
change a lot of things. We agree that the ``official'' docs shall be
|
|
build from the LUMIERA/master repository, preferably on the "devel"
|
|
VServer which has to be set up.
|
|
|
|
Conclusions: Make this final, setup build environment in the devel
|
|
server and build docs there.
|
|
|
|
|
|
|
|
NoBugFlags
|
|
~~~~~~~~~~
|
|
link:{rfc}/NoBugFlags.html[RfC: NoBug flags]
|
|
|
|
Defining a debugging control hierarchy. This is work in progress and
|
|
_Cehteh_ explains that he works it out and deploys it, this depends on
|
|
the link:{rfc}/GlobalInitialization.html[GlobalInitialization] decided earlier.
|
|
|
|
Conclusion:: accepted, finish and finalize it.
|
|
|
|
|
|
|
|
Further Technical Discussion
|
|
----------------------------
|
|
|
|
_Ichthyo_ asks how the GUI will be pulled up. Since he didn't attend IRC
|
|
discussions recently he has no information yet whats going on. We
|
|
explain him that we already made some discussions. Integrate the GUI
|
|
into the build system probably linked as library, nothing finally
|
|
decided yet. Communication will go over the plugin/interface facility
|
|
(Plain C API). This things should be worked out and documented in
|
|
link:/x/DesignProcess.html[RfCs].
|
|
|
|
_Cehteh_ made a small tool `./admin/headercheck` which will gradually
|
|
extended to proof that headers are sufficiently selfstanding.
|
|
|
|
|
|
|
|
Progress
|
|
--------
|
|
|
|
_Cehteh_ finished low level file handling and working on mmapping and
|
|
frameprovider next. When thats finished, the finalization of the
|
|
Plugin loader and interface definition things is the most urgent thing.
|
|
|
|
_Ichthyo_ works on the builder internals and next on some sort of
|
|
``connection manager''.
|
|
|
|
_Joel_ goes on with GUI programming and integrating it into the source
|
|
tree next.
|
|
|
|
_Gmerlin_ and _cehteh_ discuss about how to handle the index files which
|
|
avdecoder uses internally. _cehteh_ would like to manage them in the
|
|
Lumiera backend to, because filehandles are a precious resource.
|
|
_Gmerlin_ explains that this index files are just loaded and kept in
|
|
memory. So this poses no problem for filehandle exhaustion. We will
|
|
discuss this further via email.
|
|
|
|
_Cehteh_ suggests that we should think about some kind of
|
|
preferences/registry sometime next to store default configs.
|
|
|
|
A a discussion followed about how messages are passed between GUI and
|
|
core. Generally we will use the interfaces defined by the plugin
|
|
system. _Gmerlin_ says that he uses message queues in `gmerlin', _Joel_
|
|
requests that a lot of things should be done synchronous and he wants
|
|
to avoid message queues. _Cehteh_ suggests to use use the scheduler for
|
|
GUI things too. For the parts where the GUI interacts with the high
|
|
level proc model _ichthyo_ and _joel_ agree on working something
|
|
(synchronous) out. _Ichthyo_ stresses that the edit core is not
|
|
threadsafe by design and relies on the backends scheduler.
|
|
The underlying builder might sometimes to expensive for synchronous
|
|
calls (_ichthyo_ plans a rule system there) this needs to be worked out.
|
|
|
|
_Ichthyo_ explains that the builder needs to detect cycles and check if
|
|
the high level model is translateable into the low level model (in
|
|
case plugins git removed and so on). Parts in the render graph which
|
|
are not ``doable'' should be flagged as erroneous but not dropped since
|
|
one doesn't want to loose project information when loading a project
|
|
on a machine with different installed plugins. In any case it should be
|
|
possible that the GUI gets immediate synchronous feedback for such
|
|
things.
|
|
|
|
|
|
|
|
Next Meeting
|
|
------------
|
|
|
|
Next meeting is on 5th June 21:00 UTC
|