[gst-devel] Re: summit conclusions + plans

[Thomas Vander Stichele]

On Sun, 2005-02-20 at 22:25 -0300, Johan Dahlin wrote:
> 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.

the choices we make :) well, you watched the stream, so you were there
partly.

> 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 do count on your python work though ! Don't leave us ...

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

It is impossible to say since it really depends on whether the people
that said "I'm going to work on this piece" actually do the work.  We
don't really have anything scheduled today for 0.11 - in practice the
things that aren't ready by 0.10 will be in 0.11

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

I want to avoid the SCM discussion, that's why I think we should allow
for it.  The point is that people keep up-to-date because, when someone
is ready to merge their chunks, they have to get on the schedule,
announce their merge, and explain how it works.  So people do still get
the chance to see it.  In practice, I don't think a branch somewhere
else is watched less than a branch in our CVS, since branches in our CVS
aren't watched very actively either.

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

That's another thing - buildbot will track our HEAD branch and our
maintained branches.  You can do in your own branch whatever you like.
If you feel you should work on your branch with some other people, and
it needs the buildbot quality control, then yes, it has to go in our
CVS.  But to each their own.

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

Could work too, but otoh it's a lot of overhead for what can be avoided
completely.  We'll see how it works out.
 
> > - 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?

Schedule, since there's already a whole bunch of code ready to be
merged.  Ie, some features are more or less ready to go in.

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

Well, one thing we discussed is that we finally should have a bunch of
common base classes.  So it makes even more sense on getting the
reference right.  The ports will follow.  It's a lot better to know alsa
is right and fix oss, than it is to know that alsa is somewhat right and
oss somewhat right as well, but which is right where ?


> > - they also write some documentation and document their API
> 
> PWG? Will there be a requirement to update it before merging into HEAD?

No, the requirement is to update the "migration guide" that says how to
port plugins from 0.8 to "HEAD".  At the end of the 0.9 cycle, we start
the work to put information from the migration guide in condensed form
in the PWG


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

In practice that is not that big of a deal - a major subsystem rewrite
is not really something you want lots of revision info for.  A bunch of
incremental bug fixes is.

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

The idea is that this has to happen fast.  The idea came together like
this:
- "Let's try and chunk up all of Wim's changes instead of starting with
his branch"
- "Great, so each chunk can be for a subsystem with nice documentation
so all of us can also follow what Wim has done"
- "Hey, then we can port a second list of plugins using the information
Wim provides"
- "But then really this should be someone else than Wim doing this"

So, the idea was to allow for people to learn and pick up on what Wim
has done.  If they chose not to do this, worst case Andy or me has to
port them, and it's less useful for the others.  If that happens too
often, we should probably stop chunking because we just waste a lot of
effort doing so and no-one is following.  But if it works, this sort of
thing goes fast.

People announce "ok, I'll do that plugin", and they do it in that week,
and otherwise we move on by doing it here.  I hope though that people
take the opportunity being given by the person doing the merge.

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

The work is done in parallel. The merge is serial - we do a merge, make
sure everything goes ok, and focus on that particular subsystem for a
few days.  If we don't, we just have a core that's broken all over all
the time.

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

Not yet.  I'm starting with
- one for HEAD
- one for 0.8
- one for THREADED because it's big

>From that point on it depends on what people want and my motivation :)

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Can we, like, have a dude conversation ?
I'm begging here !
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/