[gst-devel] summit conclusions + plans

[Thomas Vander Stichele]

Hi gang,

here's a quick recap of some of the things we've discussed and decided
on during this summit.

- we want to start with 0.9 sometime soon after this weekend
- the core hackers discussed the two different approaches that have been
tried (Wim's threaded branch and Benjamin's event/trigger branch)
- ideas from both will make it in 0.9
- we'd like to try and make slightly shorter development cycles, so that
people stop stretching the development cycle to get their feature in (an
approach that has worked very well for GNOME for example)
- not every single thing needs to be changed/reworked before doing a
next stable series
- we are not necessarily going to port every single element ourselves at
every step of the way - instead we'll focus on a representative subset
of elements
- this is fine, since GStreamer is parallel-installable and applications
can choose to lag one stable series if they care more for elements than
core features.
- people should work on their subsystem rewrite in a branch, not
necessarily in our CVS (for example, benjamin's arch branch), and
prepare a largish patch to go to HEAD
- we want to put together some schedule that has tentative dates for
when features go in so people can coordinate with each other
- we want to give everyone  the chance to follow the development for
these subsystems

These basics lead to the following practical decisions:

- We will aim for a 0.10 release about three months from now - say,
Monday 16th of May.
- We aim at a feature freeze around April 20th
- People announce the core rework they want to do so it can be put on
the schedule
- the schedule contains a list of reworkings, and an explanation of how
various reworkings are connected and what sort of things are expected to
break, and what is expected to work, with checkpoints

- People prepare their core rework in a branch
- as part of this rework, they also port a first list of elements:
  x(v)imagesink, alsa, v4lsrc, vorbis, oggmux/demux, theora, vorbis,
audioconvert
- they also write some documentation and document their API
- and add some unit tests
- when this is ready, they have a big patch.  a merge date for it gets
decided
- the merge gets made, people can look at the patch, read the
documentation, ask questions on the list and irc
- a second list of elements needs to be ported by other people than the
commiter: adder, textoverlay, textparse, ffmpegcolorspace, videotestsrc,
sinesrc, tcp, gnomevfssrc, libvisual
- people volunteer for this.  this is something that needs to go
quickly, so be prepared for it.
- at the end of each of these cycles, a bunch of stuff is actually
measurable:
  - unit tests show the subsystem works
  - documentation for it has been proposed
  - people know exactly what sort of things work and do not work
  - test applications demonstrate features

This schedule will be put together over the next few days.  The
reworkings that have been discussed are:

- applying changes from THREADED (Wim)
- synchronization (Ronald)
- negotiation (David)
- logging (Benjamin)
- triggers (David)
- dparams (Stefan/Edward)
- plugins splitup (Thomas)

- As part of this approach, we will also keep docs to explain how to
migrate from 0.8 to 0.10.  These migration docs will end up being used
to rewrite the plugin writers guide soon before the release

There are some practical consequences as well.

- HEAD should remain buildable and testable during these development
cycle, but it does not necessarily mean that all apps will keep working.
You will however know why they do not work and when you can expect them
to work again.

- more buildbot stuff will be added and followed up on more consequently
to manage this new process

- it is likely that a 0.10.0 will end up getting released without all
plugins ported to it.  Applications might decide to stick with 0.8 a
little while longer.  It doesn't necessarily mean we will spend lots of
time on 0.8 fixes at that point, since it makes more sense to forward-
port elements.  People will have an easier time doing so, since more
documentation will be available for them.  This means we will need your
help.

- we seem to feel it's possible to aim for a 1.0 by the end of the year.
In practice this will of course depend on exactly what work gets done
this year, but it is felt that with the current list of things we want
changed in the core, it is achievable.

We hope this will make application developers happy, and we hope to
address the main problems today with GStreamer.

Comments ? Questions ? Flames ? Shoot !

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Nobody cares when you're gone
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/