I understand. Maybe we should convert the current Github to a real mirror, mirroring all the branches and tags as is and a) add .Travis.yml upstream or b) maintain a separate fork (maybe under my own profile) for Travis integration<br>
<br>Would you be willing to add Travis.yml upstream?<br><br>In any case, all what I'm trying to do is help, help you with more CI visibility, your users with a more familiar interface and hopefully attract more hackers. I really do appreciate all the work done, this is am amazing project!<br>
<br><br><div>On Thursday, May 8, 2014 4:49:47 PM, W. Trevor King <<a href="mailto:wking@tremily.us">wking@tremily.us</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, May 08, 2014 at 11:18:23PM +0000, Wael Nasreddine wrote:<br>
> Well like I said in my first email, if you guys are interested in owning<br>
> and maintaining the GitHub repo it is yours, besides I have not done<br>
> anything with the history I only added one commit which will never conflict<br>
> with upstream unless you add a .Travis.yml file :)<br>
<br>
I don't think merge conflicts are the problem here.  If the GitHub<br>
mirror claims to be a mirror but adds an additional commit B:<br>
<br>
  -o---o---o---A  notmuch/master<br>
                \<br>
                 B  github/master<br>
<br>
Someone who takes the “mirror” claim at face value may use<br>
github/master as the base for some feature:<br>
<br>
  -o---o---o---A  notmuch/master<br>
                \<br>
                 B  github/master<br>
                  \<br>
                   C---o---o  some-feature<br>
<br>
Now when they submit the patches to this list, they might send a patch<br>
series that drags in B (probably not what the some-feature author<br>
wanted).  Alternatively, they might send a patch series starting with<br>
C and say “this is based on B”, and anyone who's only following the<br>
main repo thinks, “What is B?  I don't have that commit.”.<br>
<br>
You'll also have to continuously rebase github/master to keep A on top<br>
of notmuch/master, which means any feature branches built on<br>
github/master will *also* have to be continuously rebased:<br>
<br>
  -o---o---o---A---D  notmuch/master<br>
                    \<br>
                     A'  github/master<br>
                      \<br>
                       B'---o---o  some-feature<br>
<br>
Keeping a fork with commits that aren't upstream is fine, and<br>
maintaining a fork with an additional .Travis.yml file will probably<br>
be pretty easy, but calling that fork a mirror is going to cause<br>
needless confusion.<br>
<br>
Cheers,<br>
Trevor<br>
<br>
--<br>
This email may be signed or encrypted with GnuPG (<a href="http://www.gnupg.org" target="_blank">http://www.gnupg.org</a>).<br>
For more information, see <a href="http://en.wikipedia.org/wiki/Pretty_Good_Privacy" target="_blank">http://en.wikipedia.org/wiki/<u></u>Pretty_Good_Privacy</a><br>
</blockquote>