LUMIERA.clone/doc/devel/rfc_pending/Roadmap-first.txt

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