On Fri, 2007-06-08 at 07:13 -0400, Jesse Keating wrote: > On Friday 08 June 2007 06:59:08 Josh Boyer wrote: > > That then begs the question as to why we can't have a simple 'make > > explode' target. Or why people can't do 'make sources' + untar > > themselves, or run rpmbuild -bp.. > > Well, untar every time and then check into an SCM to bang against may not be > efficient. You want the source already there and some history with your > patches so that the patch management system can work if you so choose to use > it. But if you're doing that much development against this code base, isn't it likely that you already have upstream's SCM repo checked out somewhere? Which you could then use for patch management... And which also encourages people to shove their changes back. Maybe what you're saying for things like the Fedora kernel makes sense. Where you have more than one or two packagers constantly dealing with updating patches, etc. > > For the vast majority of packages, I don't think having an exploded tree > > in the SCM helps anything. And it simply adds more overhead for those > > packages. > > What I envisioned is when you imported a new source it would take care of > updating the optional exploaded directory for you. When a maintainer checks > out a module from the package scm they get patches/spec/sources file per > usual. They could optionally ask to get the exploaded tree for more indepth > work, but it would be an optional thing. So thinking in SCM terms, you'd need the 'checkout' to not pull down the exploded sources by default. I'm not sure of an easy way to do that with git at the moment. Maybe hg can already do stuff like that? josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
