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

Would you be willing to add Travis.yml upstream?

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!


On Thursday, May 8, 2014 4:49:47 PM, W. Trevor King <wking@tremily.us> wrote:
On Thu, May 08, 2014 at 11:18:23PM +0000, Wael Nasreddine wrote:
> Well like I said in my first email, if you guys are interested in owning
> and maintaining the GitHub repo it is yours, besides I have not done
> anything with the history I only added one commit which will never conflict
> with upstream unless you add a .Travis.yml file :)

I don't think merge conflicts are the problem here.  If the GitHub
mirror claims to be a mirror but adds an additional commit B:

  -o---o---o---A  notmuch/master
                \
                 B  github/master

Someone who takes the “mirror” claim at face value may use
github/master as the base for some feature:

  -o---o---o---A  notmuch/master
                \
                 B  github/master
                  \
                   C---o---o  some-feature

Now when they submit the patches to this list, they might send a patch
series that drags in B (probably not what the some-feature author
wanted).  Alternatively, they might send a patch series starting with
C and say “this is based on B”, and anyone who's only following the
main repo thinks, “What is B?  I don't have that commit.”.

You'll also have to continuously rebase github/master to keep A on top
of notmuch/master, which means any feature branches built on
github/master will *also* have to be continuously rebased:

  -o---o---o---A---D  notmuch/master
                    \
                     A'  github/master
                      \
                       B'---o---o  some-feature

Keeping a fork with commits that aren't upstream is fine, and
maintaining a fork with an additional .Travis.yml file will probably
be pretty easy, but calling that fork a mirror is going to cause
needless confusion.

Cheers,
Trevor

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/<u></u>Pretty_Good_Privacy