This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [ITP] libungif-4.1.0-2

> -----Original Message-----
> From: 
> [] On Behalf Of Lapo Luchini
> Sent: Tuesday, 16 July 2002 9:16 PM
> To: Robert Collins
> Cc: 'Charles Wilson';
> Subject: Re: [ITP] libungif-4.1.0-2
> >
> >
> >What is the issue with the patch size anyway?
> >Even a 900K patch will shrink massively when bz2'd, and the 
> user doesn't
> >have to look at the content of the patch.
> >  
> >
> It's not the size, it' a question of readability... for me, 
> as a sample 
> user, I would strongly prefer to know "ahhh.. all it is needed is to 
> relibtoolize it!" instead of "urgh, it needs applying 900kb 
> of patches!!!".
> Of course this could be otherwise solved with some comments in the 
> libungif.README... but usually I prefer a "self documenting process" 
> that a "obscure process plus oducmentation".
> I see the need to hame 3 packages installed minor ni respect of the 
> uncleariness of having a gigantic patch.
> But that's me, and if everybody else thinks the other way is better I 
> have no problems in doing ni the gigantic-patch mode.

It's up to you as the maintainer, we don't have a hard and fast policy,
other than 

The key points are:
1) It must be easy and robust for users to rebuild the binary - i.e. to
add an option you left out.
(NB: I consider needing a specific version of the autotools non-robust).
2) You must document the configure arguments you used.
3) You must comply with any licence requirements (which is why method 2
ships the original source + a patch, to clearly document the changes


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]