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
pgpw8Z5up8e4Z.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
