2011/6/15 Martin Paljak <mar...@martinpaljak.net>: > Hello, > > 2011/6/14 Jean-Michel Pouré - GOOZE <jmpo...@gooze.eu>: >>> It is a bug in OpenSC. >>> Patch attached and also available at [1]. >>> Martin, please pull my master into your repository. >>> Bye >>> [1] >>> https://github.com/LudovicRousseau/OpenSC/commit/8936901e2b8fade5d9831b224f3313b7b3255133 > > I wanted to draw attention to the fact that the change can be > downloaded for testing from the Ludovic's mightly build directory on > opensc-project.org [1] by looking for a snapshot with the given commit > ID but then noticed that there's no build available with the given > commit ID. This seems to be because master was merged after the > commit, instead of rebased locally before pushing, which should be the > right way of doing it.
I don't want to rebase my master branch to not break history for others. My master branch is the "branch to merge". I think you do not have a snapshot for 8936901e2b8fade5d9831b224f3313b7b3255133 because I merged with your master a few seconds after my patch commit and then pushed to github. So 8936901e2b8fade5d9831b224f3313b7b3255133 was never the more recent commit in my github repo. > The idea is to be able to provide "usable" packages for bug reporters > or other interested parties to try out possible solutions, without > depending on trunk-sink or having to wait for a release or needing to > work with applying patches. "Please try the included patch" -> "please > try the package/installer with commit ID > 8936901e2b8fade5d9831b224f3313b7b3255133" is much more useful for > feedback. Exact. I forgot about this nice feature. > Nevertheless, the build that picked up the latter merge > (40cb1c9e35bc5efc8fd597277f7297261b6ae498) is available and includes > it [2]. Maybe splitting the builds not by user/architecture but by Git > commit would be better idea? Meaning > /downloads/nightly/40cb1c9e35bc5efc8fd597277f7297261b6ae498/opensc-snapshot.tar.gz > etc. as the commit ID is a unique flat namespace. Would require more > work and maybe not be so obvious (seeing incremental output based on > Jenkins build number, which is individual for every builder/tree would > otherwise be helpful). Suggestions on this one? I think it will be easier for me to find a tarball from my repository if it is in /downloads/nightly/ludovic Adding a counter as you did in the file name opensc-snapshot-2_40cb[...] is a very nice idea. The tarball are sorted by date. Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
