On Thu, Oct 27, 2016 at 1:53 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > On Thu, Oct 27, 2016 at 10:11 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> >> >> On 27/10/2016 17:04, Abhishek Varshney wrote: >>> If I understand the concerns right, how about doing it the other way round? >> >> That would make a lot of sense. It would however require changing the scripts that are used for the release and I suspect it won't be possible for the same reasons changing them to use the SHA1 did not happen. > > Right, I think we would need to alter the build workflow to avoid > hard-coding any version at all within /debian/changelog, so that we no > longer need to do the "bump" commit, similar to what we do for the > RPMs with ceph.spec.in. > > In Jenkins/Gitbuilder, we already have Jenkins run "dch" on every > build, to further distinguish trusty vs xenial builds that would > otherwise have the same NVR. I think we'd need to expand that concept > to also get the entire version from "git describe". > > It would be cool to have this work so we could tag/release arbitrary > SHA1s on jewel, rather than having to bump /debian/changelog on the > tip of the branch and then tag that "new version" bump commit.' Exactly. That is the actual reason why we can't really build from a sha1. However the changelog is not the only file that is now changing, the CMakeLists.txt is now affected too: https://github.com/ceph/ceph/commit/697fe64f9f106252c49a2c4fe4d79aea29363be7 If we can find a middle ground where we don't need to keep modifying these things on the fly for the build that would be easier for us as well. > > - Ken > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
