On Thu, Jun 07, 2007 at 10:25:11AM -0400, Jeremy Katz wrote:
> On Wed, 2007-06-06 at 22:46 -0400, Christopher Blizzard wrote:
> > On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote:
> > > At the same time, I think we still need to be able to very clearly
> > > separate out our changes from what upstream has.
> And fundamentally, I think that the "pristine source + patches" bit is
> just as important today as it was 10 years ago. Because otherwise, you
> get into a situation where you basically encourage forking and not
> contributing things back upstream. Your response is going to be "but
I think that maintain "tarballs + patches" is no good idea. This
thing is *very good* for distribution in src.rpms, but I hate it in
VCS. I'd like to see all code (include upstream code) in VCS.
You can still export all your changes from GIT as small patches. The
solution is branches. You can use one branch for pristine upstream
source code and other branch for upstream code + fedora patches.
Finally, you can export pristine source and patches, compress the
upstream code back to tarball and distribute the tarball + patches
by src.rpm.
My wish is "git rebase" always after upgrade to new upstream code.
The current "make prep" is nightmare...
See Linux kernel. That's normal that people maintain their patches
outside official tree(s) for pretty long time. The modern VCS is the
right tool for this job.
"separate out our changes from what upstream has" .. is definitely
no problem.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
