[gst-devel] Re: summit conclusions + plans

[Johan D. <jd...@as...>]

Hey.

Lot's of cool stuff!
I really wish I could have participated, but my recent relocation to the 
development world made it somewhat impractical.

I have some comments/suggestions. Might be out of order since I'm not 
going to be able to do any (or very little) work on 0.9. So feel free to 
ignore them.

> - 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)

Very sane choice.

> - not every single thing needs to be changed/reworked before doing a
> next stable series

Great too, not aiming for perfection is somewhat practical :-)
However, what kind of things needs to wait for 0.11/0.13?
Is there a list of things that didn't make it into 0.9?

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

This sounds less than optimal to me. It's very difficult to keep track
of changes on external repositories. I'd say that, ideally everything is 
done in the GStreamer CVS, on different branches. That makes it much 
easier for developers (and outside people aswell) to keep track of the 
the subsystem developments.
Of course, most people are not satisfied with CVS, but that something 
that everybody can agree upon and not individually setting up their own 
repo.
It also makes it difficult to support things like buildbot if people are 
doing the actual development in other places than the main repository.

Maybe a middle aproach could be reached, that people stick to their own 
repos and sync daily/weekly/whenever.

> - 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.

What's most important, schedule or features?

Are features going to control the schedule or are the schedule going to 
dictate features?

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

Only one audio sink/source? Interesting, perhaps it's better to 
concentrate on one and them port the others when it works perfectly. 
Sticking to ALSA assumes everybody develops under Linux, but I guess 
that's the case today and in the foreseeable future.

> - they also write some documentation and document their API

PWG? Will there be a requirement to update it before merging into HEAD?

> - and add some unit tests

Are there any code coverage requirements of the unit tests? What level 
of quality are the new code expected to meet?
Using gcov and covering 75%+ of the changed parts might not be a bad 
idea. Needs some infrastructure work though.

> - when this is ready, they have a big patch.  a merge date for it gets
> decided

See comments on repository; if everything is going to be one big patch 
we'll loose individual revision history of the patches.

> - 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.

To me this seems to be able to cause deadlocks in development. Are 
people going to have enough time to port plugins to each others subsystems?

> - 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)

Are all of these expected to be done in parallel? Or completely serial 
or a mix?

> 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

One buildbot for each separate subsystem branch?

I'm very happy about the general direction of GStreamer for 0.10!

Good work and good luck!

Johan Dahlin