Revision 1 as of 2008-05-23 21:04:27
converted to 1.6 markup
|No differences found!|
Should we use quilt? Why? Any exceptions? Did you used it before?
I heard is a better solution than dpatch when many patches are used in a package. I don't have any strong feelings either way, but I never used it.
Gonéri Le Bouder
I use quilt.
I've never used quilt but I heard very nice things about it. If we decided for a patching system, I think we should use only one of them, and probably quilt is better than dpatch.
Yes. It is a very nice tool. Learning curve maybe, although it should not be a problem for anyone familiar with tools like SVN or CVS. Yes, and I like it.
Never used it so far. It doesn't seem to me that it helps much with resolving conflicts nor with merging the next upstream version.
Never used it so far; but as far as I have seen/heard, dpatch and quilt do the same stuff; so I don't think using quilt would cause any bigger problems.
quilt solves all the problems I have experienced with dpatch.
Should we use plain diff.gz files? Why? Any exceptions?
As SVN handles the incremental differences in the uploads, it seems to make unneccesary the usage of a patch system, so modifying plain upstream files might be an option.
I second Miry. I just don't see much benefits of a patch system since we already use svn.
See my answer to the cdbs question.
Gonéri Le Bouder
IMO, a source package must be readable out of the box without SVN changelog. I like to have an overview of the change that the packager did by looking in the debian/patches directory. With quilt this can by done without pain.
No. I would like to avoid relying on being online for working on packages, there are also unresolved issues with my SVN access. I do not use a patch management system for packages that I am upstream of, as I can simply fix the application; it is also useless if you do not include any patches.
No for the same reasons mentioned by Linas and Gonéri.
I find this option features the best possibilites for merging upstream changes (e.g. a new upstream version) and resolving conflicts with other committers. I consider it superior over patch systems by design.
If being online is an issue, you can use svk. (or use a decentral VCS, but I don't think that this is an option for the games group, since there are many svn fans here, so I don't propose it. Yes, I like bzr).
No, we need some kind of "patch management" (in the meaning of patches to be seperated by their job). I find it just easier to read a patch description (or name) to see what it does, than to dig in svn stuff to see, why a specific change was needed. (As already explained by Gonery and Linas.) It's not that svn can't hanlde changes, but to make it easy for others to understand why those changes were made.
I think it depends on how heavily patched the packages are. For the ones I look at, which are only lightly patched, you could just annotate the hunks in the .diff.gz manually prior to generating the dsc/changes files.
No. Patch management FTW.
No. I do believe the upstream source should be left as is and only modified with a patching system during build. Sooner or later, there may be a situation where something specific needs to be done in order to build for mips or kfreebsd or some other architecture. If everything is modified at once, it could cause a build to fail on some architectures, or it could introduce changes or bugs that will impact the performance of games on certain architectures. Also, it's easier to look at a patch to see what was changed than to dig down at the source. Plus there's the added benefit of having a patch ready to send upstream.