The RfC documents were written to complement discussions of the Lumiera developers; yet since the time where ''Ichthyo'' is working basically alone on the project, this kind of discussions have ceased. During the following years, some ideas promoted by the existing RfC documents became rather detached from the actual state of development in the code base. Many of the existing RfC documents require some commentary to place them into context, and some of the decisions taken in the early stage of the project should be **re-assessed**. This includes the decision to reject some proposals, which initially might have seemed desirable, yet could not be reconciled with the understanding of the matter and topic in question, as was gained through the ongoing analysis and development.
134 lines
6 KiB
Text
134 lines
6 KiB
Text
Design Process : Manifest
|
|
=========================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2007-06-09_
|
|
|*Proposed by* | ct
|
|
|====================================
|
|
|
|
A Community Manifest
|
|
--------------------
|
|
|
|
This Proposal describes the general ideas how the community will work together
|
|
to create Lumiera.
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
Note: I start with my personal opinions, this needs to be refined and worked
|
|
out.
|
|
|
|
Please feel free to add new points or comment on things.
|
|
|
|
|
|
Background
|
|
~~~~~~~~~~
|
|
|
|
Cinelerra is quite an old project, there is an original version from
|
|
https://web.archive.org/web/20070519111115/http://heroinewarrior.com/index.php3[»Heroine Virtual« LTD]
|
|
aka »Heroine Warrior« and a community maintained version
|
|
https://web.archive.org/web/20070519204838/http://cv.cinelerra.org/[Cinelerra-CV]. ~(http://cinelerra-cv.wikidot.com/[2025])~
|
|
|
|
The original author claims that there was no-one producing useable input despite their
|
|
requests while Cinelerra was in development, and indeed the Cinelerra-CV community only
|
|
feeds back the source released by the original author into their SVN repository
|
|
and maintains few fixes. There is not much development going on. Some people
|
|
have created new functionality/features from time to time which they need
|
|
to maintain by themselves, since extensions have rarely
|
|
been merged back into the main repository.
|
|
|
|
The Cinelerra community is a quite loose group of individuals, there is some
|
|
fluctation on the developer base and almost all developers have day jobs which
|
|
restricts their involvement time on the cinelerra project.
|
|
|
|
Some of these things work quite well, there is an overall friendly relation
|
|
between the involved people. People who know C++ and have the time to edit the
|
|
source have satisfactory added their own features. The Mailing-list and the IRC
|
|
channel is also quite helpful and even new users who ask stupid questions are
|
|
welcome.
|
|
|
|
But there are some bad things too. Notably there is not much progress on the
|
|
community development. Users don't benefit from new improvements which other
|
|
people have made. There is a endlessly growing list of bugs and feature
|
|
requests, when someone sends a patch to the ML he has to invest quite some time
|
|
to maintain it until it might be merged. Finally we don't know what ``Heroine
|
|
Virtual'' is working on, until we see his next tarball.
|
|
|
|
|
|
Solution for Lumiera
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
We are in need of a new development model which is acceptable by all involved
|
|
people and benefits from the way Cinelerra development worked the years before,
|
|
without maintaining the bad sides again:
|
|
|
|
. *Make it easy to contribute*
|
|
Even if it is favorable when we have people which are continously working on
|
|
Cinelerra, it is a fact that people show up, send a few patches and then
|
|
disappear. The development model should be prepared for this by:
|
|
.. Good documentation
|
|
.. Well defined design and interfaces
|
|
.. Establish some coding guidelines to make it easy for others maintain code
|
|
written by others
|
|
.. Prefer known and simple aproaches/coding over bleeding edge and highly
|
|
complex techniques
|
|
|
|
. *Simple access*
|
|
We will use a fully distributed development model using git. I'll open a
|
|
anonymous pushable repository which anyone can use to publish his changes.
|
|
|
|
. *Freedom to do, or not to do*
|
|
The model allows everyone to do as much as he wants. In a free project there is
|
|
no way to put demands on people. This is good since it's easy to join and is
|
|
open for anyone. The community might expect some responsibility for people
|
|
maintaining their patches, but at worst, things which don't match our expected
|
|
quality and when there is noone who keeps them up, will be removed. Since we
|
|
are working in a distributed way with each developer maintaining his own
|
|
repository and merging from other people, there is no easy way that bad code
|
|
will leap into the project.
|
|
|
|
. *No Rule is better than a Rule which is not engaged*
|
|
We have to agree on some rules to make teamwork possible. These rules should be
|
|
kept to a minimum required and accepted by all involved people. It is vital
|
|
that we can trust each other on simple things, like properly formatted code or
|
|
that patches one proposes to merge don't break the system etc..
|
|
|
|
. *Legal status must be clear*
|
|
Lumiera is developed under the GPL, every contributor must acknowledge this.
|
|
Even when we provide anonymous commits, every non trivial patch should be
|
|
traceable to the person who made it, GPG signatures would be proper here -
|
|
details need to be worked out.
|
|
|
|
. *All for Lumiera*
|
|
The goal is to make the best Linux video editor to date, nothing less. Everyone
|
|
puts in their best abilities. This project is not the place to blame people for
|
|
things where they are not profound, help each other, make things right instead
|
|
of blaming someone. Everyone should rate himself at what he can do best on the
|
|
project.
|
|
|
|
|
|
Comments
|
|
--------
|
|
[underline]#This document is among the **earliest RfC**s# published in *Summer 2007*, +
|
|
as a new community movement was about to form, with the goal to improve Cinelerra
|
|
for real, in a new version Cinelerra-3.
|
|
At the beginning of 2008, this initiative had turned into a new project, with the
|
|
https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen]
|
|
name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries
|
|
were migrated from _Cehteh_'s `pipapo.org` Wiki to the
|
|
https://web.archive.org/web/20110513134311/http://lumiera.org/[new Lumiera website],
|
|
thereby mass-renaming all references Cinelerra -> Lumiera
|
|
|
|
While this »Manifest« captures well the open minded spirit of the new project,
|
|
actual development never happened in the ``community driven'' everyone pulls-from
|
|
everyone style; rather, there were immediately two, later three _core devs,_
|
|
which integrated sometimes large, yet mostly small contributions by other people.
|
|
After 2012, _Ichthyo_ kept the project going as a single developer, backed by
|
|
a small group of supporters.
|
|
|
|
Ichthyostega:: '2025-09-15'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|