[gst-devel] GStreamer needs a maintainer

[Thomas Vander Stichele]

El mié, 17-12-2003 a las 13:14, Ronald Bultje escribió:
> On Wed, 2003-12-17 at 12:28, Murray.Cumming at Comneon.com wrote:
> > > The bad thing is that *every single 
> > > commit* by someone else would cause a CVS conflict in the 
> > > ChangeLog file, because I had a bunchload of changes there 
> > > too.
> > This is a minor annoyance.
> 
> Well, I'm affraid I have to disagree there. It's a huge annoyance for a
> high-traffic project like GStreamer. It'll happen every time.
> *Literally* every time. I personally consider that unacceptable.

The problem isn't in the system, it's in the tools and how they're used.
For example, Ronald, you REALLY should look into using quilt to manage
patch sets.  I'll write up a guide on how to use it efficiently if
you're interested.  What you are saying is that "When I have loads of
changes in my branch for various things, then my ChangeLog ALWAYS
conflicts with the one in CVS".

You are right, it will if you do that.  However, the way not to have
that is pretty simple:

a) either you don't generate patch sets, in which case you don't
*actually* write your ChangeLog entry until you commit the thing, so it
won't conflict because you don't touch it unless for commiting.
b) you work with a tool that manages patchsets.  In this case, you do
something like

quilt refresh (this refreshes the current patch set you work on)
quilt pop -a (this removes all of your patchsets from the code,
effectively returning to a non-patched branch)
cvs update -dP (this gets you back in sync with CVS)
quilt push (this will reapply the first patch in your patchset; note
that this likely will not fail since the patch to ChangeLog manages to
find the right place since you haven't completely filled it)
cvs commit (this will put your patch in CVS)
remove the first patchset from your quilt control file

In any case, note that:
a) if you're doing multiple patchsets (ie, functionality-wise, say: I'm
trying to add seeking to mad, but also changing it over to the new caps
system), you're screwed on cvs commit anyway, regardless of the
ChangeLog problem.  in that case, you have to manually separate your
code chunks.  So that problem is far worse than the ChangeLog problem.
b) GNOME works so well with ChangeLogs PRECISELY because the culture
involves working on one patch set at a time, and everything is geared
towards that.  Ie, contributors generate a clean patchset, their
changelog.pl script extracts function names changed an so on (and that
works very well, I may add), and patches get applied one by one.

So, really, it boils down to a matter of methodology.

I'm mailing this out just to let you know there might be better ways of
hacking on cvs.  I've noticed sometimes you were unable to test stuff
because you had a bunch of local changes, so a tool like quilt would
help you a lot, since you could quickly revert code to a given set of
patches then try stuff out.


Will reply to pros and cons of ChangeLog in another tread.


Thomas