[gst-devel] some recent commits ...

David Schleef ds at schleef.org
Fri Apr 23 14:23:07 CEST 2004


On Fri, Apr 23, 2004 at 03:31:42PM +0200, Johan Dahlin wrote:
> > > a) back out commits that broke stuff until they work again
> > > b) have the commiter fix these issues ?
> > > 
> > Unless the committer does not seem to fix the isseue or it's a very important 
> > thing, that must run, I'd opt for b).
> > a) is most of the time not worth the effort.
> 
> 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

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

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.



dave...





More information about the gstreamer-devel mailing list