On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams <dcbw@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
