[gst-devel] cvs use

Ronald Bultje rbultje at ronald.bitfreak.net
Mon Nov 3 04:30:15 CET 2003


Hi Thomas

Just a quick-reply for now...

On Mon, 2003-11-03 at 14:00, Thomas Vander Stichele wrote:
> I would want to add more checks to these, like the automated
> media test, and more regression tests, and so on.

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.

The plugin loading interface was a good thing, btw, don't get me wrong
there. It was one of the huge issues that we needed sorted out before
1.0. However, this wasn't what I'd call "a good thing".

> But first of all, I
> would like to know what other people think we need, because it's not
> going to work unless we manage to agree on what level of quality we want
> to achieve.

I was planning on such an email, too. I didn't, because I was far too
stressed yesterday to get everything back compiling. Actually, I'm still
stressed from yesterday. ;).

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!

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.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer





More information about the gstreamer-devel mailing list