Re: patch filenames

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Jan 07, 2008 at 03:20:13PM +0100, 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. Adding
> order means that you can't just add the change and diff again, you have
> to consider whether you should modify one of the existing patch
> fragments in which case you have to regen all later patches. We do *not*
> have the tools for this.

On the contrary, this approach works very well in practice.

There are now tools to manage this sort of thing.  Even when there
aren't, all that is necessary is to delete the old patch, and append
the new one on the end.

It is quite simple to use, and very effective.
 
> 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).

I don't follow what this has to do with anything. Either a patch
is accepted upstream, or it isn't. If it is accepted, you delete
it from the patch file. If it isn't, you keep it. This actually
better than current practice, which has the effect of leaving
holes in the patch file namespace when a patch is incorporated
upstream.

Regards,
Alistair