On Tue, May 28, 2013 at 1:23 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2013-05-28 at 13:14 -0700, Luis R. Rodriguez wrote: > >> Addressing RELMOD_TYPE seems easy with --git-revision, add arguments >> additional arguments: -s -n -p -c -u as release mode specifications as >> arguments to be passed to gentree.py either as: >> >> a) standalone arguments, or; >> b) as a conglomeration of release modification types, ie something >> like --rel-mod=snpcu > > I think this would fit better with the model of a separate tool, that > calls the gentree code to generate internally. Then you'd have maybe > > ./devel/gen-and-kup.py -s -n -p -c -u ... > > or something? Overall, that seems cleaner than cluttering gentree.py > with all these options, although gentree.py would probably (internally > only?) have to learn about being able to take patches and the skeleton > code from another directory to address the paranoia for the backport > tree itself. I no longer have a need for the above. >> We just need a reasonable way to address RELMOD_UPDATE then. > > That's when you generate a new one for the same tag, due to updates, > right? Yeap. > I don't really know how to handle this -- we don't really have a > canonical database of what we've generated before. The releases we made before had patterns but I've decided that the additional patches mechanism in place before, while useful, made release management a pain. A better alternative for now is to ignore such additional patch mess under the new tree then and consider a different architecture for these modifications and consider this later with better thought if required. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
