Heads-up: brand new RPM version about to hit rawhide

[Dan Williams]

On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote:
> On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams <dcbw at redhat.com> wrote:
> > Yeah, there is actually a benefit to tarball+patches approach we take
> > right now; and that benefit is that it's extremely easy to see just what
> > we've done to the upstream package, and it's usually really easy to
> > extract those changes and push them upstream.  You don't want a
> > mega-diff that includes 20 specific patches.
> 
> I know of at least one example currently in our cvs where we went from
> a set of separate small patch files to one encompassing patch file.  I
> think it was a diff from git. If we move to more advanced vcs are we
> going to have a harder time keeping patches separated? Or is it just a
> matter of education on how not to reach for the easy to produce mega
> patch shortcut?

That's the problem here:  if we move to git (or any DVCS really), as a
packager you would have to be _much_ more aware of how to use the VCS to
achieve the same separation of patches and upstream source.  You'd need
to do something like topic branches for each patch and then merge each
topic branch into a "release" branch to ensure that each of the patches
was cleanly separated from the main source.

Basically, moving to a DVCS and exploded source trees just raises the
bar for packagers since they'd have to learn quite a bit about how DVCS
works.  CVS + tarball + patches are quite easy for most people to learn,
but a DVCS + branches + merges is much more complicated if the
changesets are small.  And the changesets should always be small,
otherwise we're completely failing at pushing stuff upstream.

Maybe the fix here is to let package maintainers who want to use a DVCS
style, and those that don't want to use the old style, and provide the
ability to switch between the two styles when a new maintainer takes
over the package?

Dan