On Thu, May 23, 2013 at 2:02 PM, Luis R. Rodriguez <[email protected]> wrote: > I see what you're saying now and I actually did consider it, the > reason I didn't use --git-revision is speed. Git reset --hard tag, and > then copying the code directly is a lot faster. The race issues you > point out though are worth reconsidering this though.
I've given this some thought and I find that the theoretical race conditions also applies even if you use --git-revision on the output path. A true paranoid release model would then have a target output directory only the parent process and children could modify / update but given it seems we have considerations for non ext[34] filesystems (recent kconfig patch) its unclear we could resolve this for the truly paranoid. The speed considerations I raised then (10 seconds as of next-20130523 with python-git installed) could be discarded in favor of consistency of just using --git-revision for a release model provided we also address the RELMOD_UPDATE and RELMOD_TYPE specification for both daily and stable releases, defined on the upload_release() documentation. Right now we infer RELMOD_UPDATE based on the output directory but inferring RELMOD_TYPE from the same target output directory would be sloppy IMO so tackling these two with --git-revision would need to be addressed. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
