[gst-devel] some recent commits ...

[Thomas Vander Stichele]

> > I'm not sure if b) is going to work out. IMHO CVS HEAD should always
> > stay working with all applications and all support formats.
> > If someone breaks it, it should be fixed. Most of the times the
> > developers are available on IRC or mail etc. But sometimes it can take a
> > little while, a couple of hours, a day. In these causes I don't think b)
> > is acceptable. Since it can force quite a number of people to just sit
> > and no wait for the checkin to fixed. Time's wasted a people get pissed
> > off. 
> 
> cvs co -D yesterday

... which is pretty useless as well if there are no attempts at keeping
the tree buildable :) it might be just as broken.

> Let's not spend too much time on making sure everyone can build and
> run the tree 100% of the time.  We don't have an infinite amount
> of development time, and we have a small number of developers.

Right, but there are developers that seem to care about this, so I
personally don't see what would be the problem with allowing them to do
this.  The person who broke it in the first place obviously is going to
have to spend time anyway on fixing what he broke, so he doesn't lose
any more time when someone else reverts it.

So unless there's good reason not to have people revert broken checkins,
I don't see why they can't spend their time doing so if they want stuff
to work.

>   I
> don't personally ever lose time over broken checkins -- I revert
> and move on.  Of course, I want people to avoid breaking the tree
> whenever possible, but my primary goal is for us as a development
> group to produce the most good code as possible.  Broken trees
> don't get in the way of producing code as much as, say, running
> 'make distcheck' before every checkin or (ahem) even making sure
> the docs build.
 ... Which is why time is being spent on the buildbot so that those
of us who really don't want to run make distcheck when they make
important build changes can at least get some verification about their
bold selfassumptions :)

> On the other hand, if you want to provide a close-to-up-to-date
> tree that always compiles, you can easily keep a moving tag
> that points to the last checkin that build properly on all
> systems.  When a build works after a new, just retag the changed
> files.

IMO that's even more waste of time, and putting the effort on the people
that try to keep things working :)

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
God how I hate myself for
still wanting her
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/