Hi Loic, It is definitely a great idea to have all the backport snippets under a roof. However, these snippets, which are mostly a set of commands, provide great flexibility in terms of configuration and the ability to partly execute them. For instance, if I see conflicts while preparing an integration branch, I comment out the git fetch, checkout and reset steps from [1] after resolving the conflicts and re-run the snippet. It would be nice if we can incorporate all the snippets and take ceph-workbench to that level of flexibility :) [1] http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_populate_the_integration_branch Thanks Abhishek On Thu, Nov 5, 2015 at 6:50 PM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > Hi, > > Today, Nathan and I briefly discussed the idea of collecting the backport snippets that are archived in the wiki at http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO. We all have copies on our local disks and although they don't diverge much, this is not very sustainable. It was really good as we established the backport workflows. And it would have been immensely painful to maintain a proper software while we were changing the workflow on a regular basis. But it looks like we now have something stable. > > Early this year ceph-workbench[1] was started with the idea of helping with backports. It is a mostly empty shell we can now use to collect all the snippets we have. Instead of adding set-release[2] to the script directory of Ceph, it would be a subcommand of ceph-workbench, like so: > > ceph-workbench set-release --token $github_token --key $redmine_key > > What do you think ? > > Cheers > > [1] https://pypi.python.org/pypi/ceph-workbench > [2] https://github.com/ceph/ceph/pull/6466 > -- > Loïc Dachary, Artisan Logiciel Libre > -- 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
