Patch names (security, fixes)

[Robert Connolly]

On Thursday October 23 2008 04:53:37 pm Ken Moffat wrote:
> In ticket 2227, Robert wrote
>
> |I also suggest that we name upstream patches "fixes", not security
> |or whatever else. At the same time, don't name non-upstream patches
> |"fixes".
> | This might start another LFS bug issue, but it's worth mentioning
> |here.
>
>  This needs to be discussed *here* ;)
>
>  Personally, whenever I create a patch I find it hard to create an
> *appropriate* name.  Often, putting 'fix' in the name helps me
> understand what it is for without looking at the content.  I find it
> hard to see *why* restricting "fixes" to only those patches which have
> come from upstream is going to help anyone ?
>
>  The grammarian within me says that _fixes patches should always
> contain fixes for more than one issue. ;)
>
>  And then, if there are known vulnerabilities but no upstream patch,
> how are you going to name a patch ?  For a single vulnerability you
> could name it fubar-0.9-CVE_2008-9990-1.patch, but what if there are
> a *series* of CVE numbers for related issues which all need to be
> patched ?

I'd just like something that we can all agree on, and use.

How about "upstream_fixes" for bug patch(es) which are in upstream, 
and "community_fixes" for other bug patch(es) which are not in upstream? and 
stop using "security" in patch names, because bugs are bugs.

For our purpose, we can use a plural "fixes" even if the patch only fixes one 
issue, because it may be added on to later. Just to keep the naming coherent.

Other patches would typically be feature additions, and can be named according 
to that.

If one patch depends on another, upstream comes first, then community, then 
features.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20081023/e3555503/attachment.bin