[gst-devel] state of the union

[Thomas Vander Stichele]

El vie, 09-01-2004 a las 14:19, Benjamin Otte escribió:
> On Thu, 8 Jan 2004, Julien MOUTTE wrote:
> 
> > > An example was the improper overlay handling of ximagesink, that obviously
> > > hadn't been tested yet.
> >
> > And that's a good example you are triggering here. ximagesink has been
> > modified and it was not working anymore.
> >
> Write a test if you want to be sure it's always working. I tend to run
> testsuites before checkings, especially if it's not my code.

Add make distcheck to your testsuite :)

> > so i have something working here, someone got an issue with it then
> > modifies it and now it s not working anymore at my place.
> >
> > It would be much more simple to just tell me what was going wrong with
> > this implementation and i try to fix it.
> >
> No it would not. The stuff I'm doing requires a working videosink, so if I
> have to wait to grab you and tell you to fix it and then wait for you to
> actually do it, that might take loads of time, which IMO is not acceptable
> for important plugins.

There is nothing stopping you from having local changes.  If you want to
commit those for everyone, it is only natural that, when there is
disagreement from the person who wrote most of the code or last rewrote
it cleanly, that you need to agree on what to change.

FWIW, looking at the diffs, it seems you are not applying the same sort
of fixes to both ximagesink and xvimagesink.  You are making it hard for
the person maintaining the rest of those source code files to do his
job, just because you want to quickfix to work on your machine.

> > I spent some hours reverting many changes in ximagesink to bring it back
> > to an acceptable state and that's exactly why i agree when thomasvs says
> > that we need to have someone being responsible of things.
> >
> > So if current ximagesink is broken on your machine i will be happy to
> > try to fix for you.
> >
> I have the test in libgstui in my local CVS. If it doesn't work anymore,
> I'll let you fix it (either the test or ximagesink ;).

If he can't get the test he can't test what breaks for you.  If you
break it for him, but he wrote most of it and it worked fine for him,
it's your job to make it better by making sure it works for the two of
you.  It's basic respect for each other's work, I think.

I often have to do the same - when I try to get a subsystem fixed (say,
the docs build), I try to make sure that people on, say, debian, test it
as well.

If all the "fixes" do is make it work for a set of persons A different
from a set of persons B so that A doesn't include B anymore, the fix is
obviously wrong.

Anyway, can we not argue about silly points like these ? Julien did a
good job at cleaning the two sinks up, and I want to make sure he sticks
around to do that job.  I don't want him to stop doing it because
someone feels he has the freedom to quickfix without discussing.

Just like I don't want you to leave because you feel you get your
freedom taken away.  Let's respect some simple boundaries so we can get
work done.

If people disagree, feel free to pipe up.  For me, it seems a very
simple natural rule that "if someone did a lot of work on a piece of
source, you have to make it possible for him to keep doing his job". 
Beyond that, parties involved need to cooperate :)

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If you want love
we'll make it
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/