On Tue, 2008-07-15 at 12:24 -0400, Dan Williams wrote:
> 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.
Indeed, the workflow is different, but only in implementation. You
still adhere to the same principles with the tarball + patch approach.
So, it's mainly just a matter of keeping someone from being lazy with
the scm instead of doing things the right way, and providing
documentation on what the right way is.
> 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?
Certainly, there's no need to force any maintainer to switch the
packages they take care of, so you will probably always want to support
both ways of doing things.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
