On 13/09/2015, 00:11, "gem5-dev on behalf of Ali Saidi" <[email protected] on behalf of [email protected]> wrote:
> > >> On Sep 4, 2015, at 12:54 PM, Steve Reinhardt <[email protected]> wrote: >> >> To answer Jason's question: it would be nice to have an automation >>system >> where someone with sufficient permissions could just click on a patch on >> reviewboard and the patch would automatically be committed; with that >> process in place, it doesn't seem like much of a stretch to include the >>URL >> in the commit message. I know Ali has discussed some other tools that >> enable this. The easiest path to this kind of functionality might >>require >> migrating to something other than reviewboard. >> >> Steve >> > >I completely agree. Unfortunately, the tool I was hoping would do that >(kallithea) doesn¹t seem to. The current choice we have for this function >are: > * Gerrit (git only) not clear what benefit it provides above and beyond >other options > * Bitbucket (git or mercurial) > * github (git only) > >We can certainly do this with limited impact to people by migrating to >bitbucket although github is more popular. I have spent some brain cycles on this and I think we could pull off a relatively painless migration to GitHub. This is probably a good long-term solution since people tend to be familiar with git and GitHub. In fact, we already have a total of 26 forks on GitHub. There are several more that weren¹t cloned from any of the (semi-)official mirrors. We already have GitHub mirror that¹s automatically kept in sync (as a commit hook) with the Mercurial repo. We could switch the repos and make the Mercurial repo the slave and the git repo the master. This would mostly affect people with commit accesses. One issue when doing this is that commit IDs of past commits won¹t be compatible when pushing things from GIT. This might not be a big issue in practice since most people seem to be using patch queues on top of a clean repository. Current maintainer flows would (mostly) just work as Mercurial is able to interact with git repositories using the hg-git extension. We already use this functionality to synchronize the mirror. The biggest problem in this setup is that the initial clone will be pretty slow (~10 minutes). Another option for maintainers would be to use a hybrid hg/git flow. In the past (before switching to a pure git flow), I used to import MQ patches into git repositories. This type of flow could be used to convert work in, for example, a shared patch queue to git commits. //Andreas IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
