[gst-devel] cvs use

Benjamin Otte in7y118 at public.uni-hamburg.de
Mon Nov 3 04:58:10 CET 2003


On Mon, 3 Nov 2003, Ronald Bultje wrote:

> That wouldn't help. In one of my mails on gst-devel, I complained about
> one of the changes of yesterday, saying that "you (Benjamin) didn't
> check for regressions and didn't run the test suite". It literally broke
> everything except spider-based apps, and he didn't even know! This way,
> test suites don't help. People need to start thinking a bit more before
> redesigning. So in short: yes, we need more discussion before such
> breaks.
>
Hey, it works again. There was just one thing I was missing.

> Just to make things clear: guys, we have a huge load of apps (RB,
> gst-player, totem, gst-editor, gst-rec, marlin, ...) that all need to
> *work*. We can't just change a whole interface, test it with one app and
> assume it's fine. If you change something, ask first. If you don't
> understand something, ask first; don't remove it "and see what happens",
> and definately don't implement workarounds for issues that are a
> consequence of your changes (grr!) and think that others will accept
> that (grr!). That's all plain wrong. Different apps have different
> requirements, and that's why GStreamer is so large and complex: to
> accomplish this all!
>
GStreamer is still so broken right now, that it still needs large
architectural changes to be even a bit useful for anything but Rb-Style
CREATE => PLAY => DESTROY.
Until perfect video without threads, replugging and SMP works, I'm not
even going to care wether I'm breaking a thing when I think it is
needed.
I will certainly discuss it with you before.

> In short: I fully agree with Thomas. We need more discussion before such
> breakages. I don't know about a policy, but then again, this is just a
> quick-reply. I might come up with something better tonight.
>
> As a start, I'd like to propose an internal "light API freeze" for half
> november, from where on we will not break API anymore (unless there's a
> very good reason, and with prior discussion). ABI breakage is still
> allowed until the Gnome-2.6 API/ABI freeze. From that point on, I'd like
> to focus on things like documentation, so that we can actually document
> this. Our documentation is bad right now (PWG, etc.). Also, we need one
> or two persons to focus on i18n for a few weeks. I i18n'ed gst-rec and
> gst-mixer already, which completes our apps-i18n'ing. However, gst-core
> and gst-plugins still need doing, I'd like to focus on that next.
> Speaking of which, how's the error-branch going? That's (afaik) the last
> "big" change needed before we're "API ready" for Gnome-2.6.
>
Tags.
Navigation.

I will stop making ABI/API changes after ABI/API freeze. Not before.
Ensuring stability can happen then. You are aware that we are talking
about cvs HEAD here, not anything that has to be stable right now.


I'm so fed up with people complaining about stability of the stuff they
are doing while they don't even understand how GStreamer works. GStreamer
is fundamentally broken in many ways _right_now_. If you do not understand
why and where (and in my arrogance I assume from my talks with you that
you are not), there is no point in even discussing why changes are needed,
because you will not understand.

I'm really pissed right now at people telling me that cvs activity is a
bad thing and makes them afraid and othe people telling me I only care
about my own app.
I encourage all of you to present me your architecture ideas of the core
that fix SMP and replugging in active pipelines.

Benjamin






More information about the gstreamer-devel mailing list