On 07/01/2008, at 15:20, Joerg Sonnenberger wrote:
On Mon, Jan 07, 2008 at 01:50:01PM +0000, Alistair Crooks wrote:On Mon, Jan 07, 2008 at 01:30:12PM +0100, Joerg Sonnenberger wrote:On Sun, Jan 06, 2008 at 12:50:44AM +0100, Roland Illig wrote:3. Group functional changes into one patch file:Absolutely rejected. This is a nightmare for maintainance.I disagree, having designed and used a packaging system which used this infrastructure. It works very well, is kind to the SCM, and is efficient to the point of brevity.I regulary have to deal with files that are patched already. Addingorder means that you can't just add the change and diff again, you haveto consider whether you should modify one of the existing patchfragments in which case you have to regen all later patches. We do *not*have the tools for this.
We *do*. Again, see devel/quilt. Whether you like it or not, that's another story.
I also don't buy the argument that it makes pushing patches upstream easier. From the long list Roland posted, a lot of them are either essentially dead (xview) or notorous for not accepting proper patches for years (mozilla).
Right. So, for example, you have to send a patch upstream that adds __NetBSD__ checks everywhere alongside some existing __FreeBSD__ ones. These changes affect several files. With the current approach you have a gazillon of different patch-* files, one for each, that are not related in any way, when, conceptually, they really are related because they are fixing the exact same problem in multiple places.
Then, to make things worse, some of these patches also have other completely-unrelated stuff in them, say because they are dealing with the sysconfdir stuff. This also affects multiple files.
Now, how is it easy to send the first set of patches (the __NetBSD__) ones upstream? It is not. You have to go, mix them in a single patch, remove all garbage that does not belong there and then send the resulting file upstream, which at this point has no relation with the patches in the pkgsrc tree. That becomes very, very boring, and even more, makes tracking upstream patches very hard because they have no direct correspondency with the ones in pkgsrc.
-- Julio M. Merino Vidal <jmerino%ac.upc.edu@localhost>