On Tue, 2013-05-28 at 13:02 -0700, Luis R. Rodriguez wrote: > On Thu, May 23, 2013 at 2:02 PM, Luis R. Rodriguez > <mcgrof@xxxxxxxxxxxxxxxx> 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. Well, to be honest, you have to trust the system anyway, otherwise it can mess up completely. So I guess the race is pretty much unimportant. It was just an additional thing to consider, more in case you start this as a long-running process and then (accidentally) work with the linux-next tree in another way. However I'd argue that since the git object database would typically be corrupted by changes impacting --git-revision usage, it's still a lot safer than using checkouts. > 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. Well like I said before, I think you should probably just write a separate script (possibly as a devel/ script) that you'd do something like ./devel/gen-and-kup.py /path/to/linux-next/ next-20130528 and then it would internally create a temporary directory (with tempdir thing) and run something like ./gentree.py --git-revision next-20130528 /path/to/linux-next/ /tmp/tmpdir/<relname>/ (obviously not calling the script but rather the function like git-tracker does) and then work in /tmp/tmpdir/ to create the tarball etc. That way, you don't have temporary stuff lying around after the generation, and get rid of many of the changes you're making here since you wouldn't need the paranoia stuff. johannes -- 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
