On Sat, 2007-06-09 at 10:01 +0000, Bojan Smojver wrote: > > I think that would be the least of the problems with this approach. > Because we're building from pristine sources with patches now, every > maintainer is best off with zero patches to the pristine source. So, > every maintainer has an incentive to fix the upstream source so that > the next release comes as close as possible to the spec file created > by fedora-newrpmspec. The integrated approach would turn package > maintainers into fork maintainers. Sure, having a patch-less spec file is the ideal but it's not always possible. At the minimum there will always be some packages that have patches that implement Fedora-specific policy (e.g. changing default values in configuration files) that would be inappropriate to send upstream. There are also many instances where Fedora needs to carry a patch for a while (e.g. a security patch backported from a newer release than Fedora ships because the Fedora package can't be updated for some reason). So unless package maintainers in some sense are already and will always be "fork" maintainers - minimizing the number and size of changes from upstream is an important goal, but it's not the only goal. What this discussion has been about is bringing patch development out of a hidden corner the package maintainer's laptop hard drive and into a centrally maintained, publicly available version control repository. > Having one giant integrated repository would make the work of going to a brand > new upstream version very tedious, as all Fedora specific changes would have to > be identified and extracted out of the repository first and then reapplied to > the new tree. With the current approach, the separated patches already exist. If > they don't apply to the new pristine source, it's either because they are > incompatible, which the maintainer can fix, or are no longer required and the > maintainer can drop them. Far less work. Apparently you have never used a version control system that properly supports branching and merging. CVS and Subversion do not count. Git, Mercurial, and Bazaar are ones that do and make it easy (in some cases trivial) to maintain code/patches in branches and then rebase the patches to new versions of the upstream code as they are released. With the proper discipline, keeping track of the changes that we have made to the pristine code isn't really a problem. However, I don't want this thread to descend into a debate about the best revision control system. We need to be discussing things at a higher level right now. Jeff
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
