Should we use quilt? Why? Any exceptions? Did you used it before?

Eddy Petrișor

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.

Miriam Ruiz

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.

Linas Žvirblis

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.

Reinhard Tartler

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.

Alexander Schmehl

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.

Sam Hocevar

quilt solves all the problems I have experienced with dpatch.

Should we use plain diff.gz files? Why? Any exceptions?

Miriam Ruiz

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.

StefanPotyra

I second Miry. I just don't see much benefits of a patch system since we already use svn.

Jon Dowland

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.

Linas Žvirblis

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.

Eddy Petrișor

No for the same reasons mentioned by Linas and Gonéri.

Reinhard Tartler

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).

Alexander Schmehl

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.

Jon Dowland

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.

Sam Hocevar

No. Patch management FTW.

Andres Mejia

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.