[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[]
