Patch names (security, fixes)

[Robert Connolly]

On Thursday October 23 2008 10:11:44 pm Bruce Dubbs wrote:
> Robert Connolly wrote:
> > 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.
>
> I like that.  We don't need to go and rename everything right now, but we
> can do that for any new patches.

What about Binutils cvs branch updates? Does this count as upstream_fixes? 
Because bug fixes are usually backports, not cvs branch updates.

And, what about feature additions backported from upstream?

upstream_branch_update <-- essential patch
upstream_fixes <-- essential patch
community_fixes <-- essential patch, justified for some reason
upstream_somefeature <-- optional (typically hints or hlfs patches)
community_somefeature <-- optional (typically hints or hlfs patches)
cross_something <-- clfs patch

?

The Bash and Ncurses patches would fit under upstream_fixes.

Some patches would end up with fairly long names, like:
glibc-1.2.3-community_localedef_trampoline-x.patch

But I think this naming would help our users understand the patches a bit 
better.

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/92362aa5/attachment.bin