176 lines
7.6 KiB
Text
176 lines
7.6 KiB
Text
[grid="all"]
|
|
`------------`-----------------------
|
|
*State* _Idea_
|
|
*Date* _2009-01-30_
|
|
*Proposed by* link:Ichthyostega[]
|
|
-------------------------------------
|
|
|
|
|
|
|
|
Roadmap up to Lumiera 1.0
|
|
-------------------------
|
|
|
|
As the very basic architecture questions seem to settle down now, it seems to be time
|
|
to create a first Roadmap skeleton for the project. A specific approach is proposed:
|
|
we should define criteria allowing us to judge when we've reached a certain level
|
|
plus we should define features to be ''excluded'' at a certain level. We should
|
|
''not'' define ''Features'' to go into a certain level.
|
|
|
|
''the following text is copied from the Lumiera http://issues.lumiera.org/roadmap[Trac]''
|
|
|
|
|
|
Description: Milestones up to first Release
|
|
-------------------------------------------
|
|
|
|
|
|
Milestone integration: cooperating parts to render output
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
For this milestone to be reached, the basic subsystems of Lumiera need to be designed, the most important interfaces between
|
|
the parts of the application exist in a first usable version, and all the facilities on the rendering code path are provided
|
|
at least in a dummy version and are '''capable of cooperating to create output'''. Based on Lumiera's design, this also means
|
|
that the basic frame cache in the backend is working. And it means that a media asset and a clip can be added to the internal
|
|
session representation, which is then handed over to the builder. Probably it's a good idea to include basic playback/display
|
|
of the rendered frames within the GUI while they are created.
|
|
|
|
|
|
Notable features ''not'' included
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
* no saving and loading of sessions
|
|
* no manipulation of objects though the GUI (just display of the session)
|
|
* no adding of arbitrary media or inclusion of arbitrary plugins
|
|
* no media stream type conversions
|
|
* no playback of sound
|
|
|
|
|
|
Milestone alpha: operations accessible for users
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
For this milestone to be reached, the fundamental operations you'd expect from a video editing software
|
|
can be '''accessed by a user''' (not a developer!). This means that the basic distribution/release model
|
|
is set up, a ''user'' is able to compile Lumiera or install an existing package. Moreover a user should
|
|
be able to create/open a session file (without any quirks), add some media (probably only a limited number
|
|
of media types will be supported), and then perform the most basic operations like positioning, trimming,
|
|
copying, playing and finally rendering the timeline integration phase is closed and Lumiera has reached alpha level.
|
|
|
|
|
|
Notable features ''not'' included
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
* advanced configuration
|
|
* complex/compound projects
|
|
* meta-clips, multi-cam, advanced multi channel sound handling
|
|
* any asset management beyond the very basic media handling
|
|
* advanced wiring and routing
|
|
* media stream type conversions
|
|
* adding of arbitrary plugins
|
|
* proxy editing
|
|
* configurable GUI
|
|
|
|
|
|
Milestone beta: usable for real work
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
For this milestone to be reached, users should be able to '''get real work done with Lumiera'''. Especially,
|
|
a basic asset management should be in place, Lumiera should be able to handle the most common media types,
|
|
the user should be able to do common editing tasks (adding, trimming, rolling, splicing copying, moving)
|
|
both by direct manipulation within the timeline, as by using the conventional two-viewer setup with
|
|
in/out points. Moreover, it should be possible to attach effects (probably still just some limited kinds
|
|
of effects), apply simple transitions and control the layering and overlay mode on output. Similarily,
|
|
the elementary routing capabilities and the handling of multiple sequences should be suported (probably
|
|
still with limitations). The framework for automation handling should be in place, while there may be
|
|
still limitations on automation/keyframe editing. Having about this feature set indicates, that Lumiera
|
|
entered the beta phase.
|
|
|
|
|
|
Notable features ''not'' included
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
* configuration editing through the GUI
|
|
* advanced routing, full support of virtual clips
|
|
* arbitrary wiring, macro effects or similar
|
|
* view or editing of individual nodes
|
|
* arbitrary nesting and navigation within projects
|
|
* full multi-cam support, support for non-standard image/sound types
|
|
* plugin libraries and packaging
|
|
* interfaces for plugin authors are not frozen!
|
|
* fully configurable GUI
|
|
* full support for proxy editing everywhere
|
|
* extended workflow features (like "export to DVD")
|
|
|
|
|
|
Milestone release-1.0: usable for productions
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
For this milestone to be reached, Lumiera should be a '''reliable tool for productions with a deadline'''.
|
|
Lumiera 1.0 is not the ''dream machine,'' but users should be able to do simple productions. We should be
|
|
able to promote Lumiera to professionals without remorse. The GUI should be mature, undo/recovery should
|
|
work airtight, performance should be ok-ish and output quality without any glitches. Plugin authors
|
|
can rely on stable interfaces and backwards compatibility from now on, up to release 2.0
|
|
|
|
|
|
Notable features ''not'' included
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
* bangs and whistles
|
|
* render farm, distributed execution, hardware acceleration
|
|
* MIDI and adding of non-standard media kinds yet-to-appear
|
|
* advanced media management, full support for subtitling
|
|
* support for special workflow features
|
|
* foreign session import/export
|
|
* collaboration features
|
|
* artificial intelligence
|
|
|
|
|
|
|
|
|
|
Tasks
|
|
+++++
|
|
Please review and discuss this proposal, consider if it's of any use setting it up this way...
|
|
|
|
|
|
Pros
|
|
^^^^
|
|
* doesn't hinder us
|
|
* helps to avoid controversies
|
|
|
|
|
|
|
|
Cons
|
|
^^^^
|
|
The contents of the roadmap aren't very specific and thus aren't of much help
|
|
for determining ''what has to be done next.''
|
|
|
|
|
|
|
|
Alternatives
|
|
^^^^^^^^^^^^
|
|
* Create a complete development plan and derive the roadmap from it.
|
|
* Use no roadmap at all beyond the next forseeable minor release.
|
|
|
|
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
|
|
We deliberately don't set any date schedule. Releases happen ''when they are ready.'' We may decide to do sprints on
|
|
a short-term timeframe, but it doesn't help promising things we can't calculate for sure. In an commercial setup, you
|
|
have to commit to features and dates, but you also control a certain budget, which gives you the means to ''make things
|
|
happen.'' In Open Source development, we've to be patient and wait for the things to happen ;-)
|
|
|
|
Thus the proposal is to set up just a very coarse and almost self-evident roadmap skeleton, but to discuss and define
|
|
criteria up-front, which allow us to determine when we've actually reached a given level. Moreover, the proposal is
|
|
to add a list of features which can be savely ''excluded'' from the given milestone
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
Looks ok to me, the dust is settling ad we can now think about such a roadmap. Some goals might be shifted between Milestones on collaborative decision, but so far I agree. Otherwise I'd like to keep the issue tracker focus on work to be done, it shall not become a wishlist tool for non developers, any such things are deliberately left out.
|
|
-- link:ct[] 2009-01-31
|
|
|
|
In ticket #4 (debian packaging) i explained that packaging might be optional for 'alpha' and should be moved to 'beta'.
|
|
-- link:ct[] 2009-02-01
|
|
|
|
OK, we should make the packaging optional. I think, for alpha the criterion is "accessability for users". If compiling remains so easy as it is now (compared with other media related projects), than this shouldn't be a barrier.
|
|
-- link:Ichthyostega[] 2009-02-01
|
|
|
|
|
|
Back to link:Lumiera/DesignProcess[]
|