Maybe a crazy idea: If we have a main repository and a Bitbucket mirror, we could add a hook on every commit to the main repository that replicates the commits to the mirror.
If someone opens a pull request a reviewer (with commit rights to the main repository) can review the pull and comment with "r+" (review positive), then a bot will check if the pull is mergeable to the main repository and runs the complete tests suite. If the pull is not mergeable the bot will try to automatically merge changes to the default branch from the main repository into the PRs branch. If the merge or tests fail the bot will add a comment to the PR. Mozilla Rust's bot "bors" is an example for a bot that works in a similar way in practice. With ~50 merged commits last week [1]. There is a recent article (yesterday) that writes about bors "successor" [2]. Unfortunately bors is written with Git in mind. There is also a viewable queue for the pull request auto-merge bot at [3]. [1] https://github.com/bors [2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/ [3] http://buildbot.rust-lang.org/bors/bors.html On 3/18/15, Benjamin Gudehus <hasteb...@gmail.com> wrote: > Ah I see, that's reasonable. > > Using patch files sounds like the change sets will be really > scattered. I first thought about an "official" Bitbucket mirror that > acts as a gate and only accepts small pull requests where every author > identified by his/her email address has accepted the OCA/CLA. There > also is a synchronization between the main repository and the mirror, > where the default branch is merged between both. I don't know if this > is feasible, sounds like a lot of coordination work, e.g. the people > from Node.js and its fork io.js have some problems with coordination > between both repositories. > > > > > > On 3/18/15, dalibor topic <dalibor.to...@oracle.com> wrote: >> On 18.03.2015 06:50, Benjamin Gudehus wrote: >>> >then you have to spend weeks sorting out who contributed to the files >>> in the pull request >>> >>> Is it common to have multiple authors for a single pull request? >> >> It's fairly easy to create scenarios with multiple authors: >> >> A forks away, patches, B forks from A, patches again and submits some >> sort of 'pull request' to the mailing list incorporating both change >> sets. >> >> cheers, >> dalibor topic >> -- >> <http://www.oracle.com> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 >> <tel:+491737185961> >> >> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 München >> Registergericht: Amtsgericht München, HRA 95603 >> Geschäftsführer: Jürgen Kunz >> >> Komplementärin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> <http://www.oracle.com/commitment> Oracle is committed to developing >> practices and products that help protect the environment >> >
