Github?

Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Hello everyone,

Thank you so much for creating Notmuch, I am coming from sup and I was
looking for a more stable alternative and I think I found what I am looking
for :)

I was a bit disappointed that the project is not living (or at least
mirrored) to Github, it would have made my search much easier. Any thoughts
on moving to Github? I took the liberty of making the first move by
creating https://github.com/notmuch and splitting the contrib/ and binding/
into their own repository (conserving all their history).

@owners and devs, if you'd like to explore the Github option more I'd be
happy to grant you admin rights of the notmuch Github organisation.

Thanks,

Wael

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

I forgot to mention that I also enabled Travis-CI for notmuch, you can
access it here <https://travis-ci.org/notmuch/notmuch>, there are 33 failed
tests, they are also failing on my own machine.

On Wed May 07 2014 at 10:28:06 PM, Wael Nasreddine <
wael.nasreddine@gmail.com> wrote:

> Hello everyone,
>
> Thank you so much for creating Notmuch, I am coming from sup and I was
> looking for a more stable alternative and I think I found what I am looking
> for :)
>
> I was a bit disappointed that the project is not living (or at least
> mirrored) to Github, it would have made my search much easier. Any thoughts
> on moving to Github? I took the liberty of making the first move by
> creating https://github.com/notmuch and splitting the contrib/ and
> binding/ into their own repository (conserving all their history).
>
> @owners and devs, if you'd like to explore the Github option more I'd be
> happy to grant you admin rights of the notmuch Github organisation.
>
> Thanks,
>
> Wael
>

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

Re: Github?

[Jani Nikula]

On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com> wrote:
> Thank you so much for creating Notmuch, I am coming from sup and I was
> looking for a more stable alternative and I think I found what I am looking
> for :)

Great, thanks for your interest in notmuch!

> I was a bit disappointed that the project is not living (or at least
> mirrored) to Github, it would have made my search much easier. Any thoughts
> on moving to Github?

http://mid.gmane.org/87wqea7c37.fsf@nikula.org

> I took the liberty of making the first move by
> creating https://github.com/notmuch and splitting the contrib/ and binding/
> into their own repository (conserving all their history).

I am concerned people will mistake that for the official notmuch
repository.


BR,
Jani.

Re: Github?

[Jani Nikula]

On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com> wrote:
> I forgot to mention that I also enabled Travis-CI for notmuch, you can
> access it here <https://travis-ci.org/notmuch/notmuch>, there are 33 failed
> tests, they are also failing on my own machine.

Apparently the test suite does not handle missing dependencies
gracefully; please install dtach(1) on the machines and try again.

You might be interested in checking out our buildbot that runs the test
suite too [1], linked from the notmuch home page.

BR,
Jani.


[1] http://buildbot.notmuchmail.org/grid

Re: Github?

[Eric]

On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula <jani@nikula.org> wrote:
> On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com> wrote:
>> Thank you so much for creating Notmuch, I am coming from sup and I was
>> looking for a more stable alternative and I think I found what I am looking
>> for :)
> 
> Great, thanks for your interest in notmuch!
> 
>> I was a bit disappointed that the project is not living (or at least
>> mirrored) to Github, it would have made my search much easier.

Meaning that you start with the idea that everything should be in
Github???

>> Any thoughts on moving to Github?
> 
> http://mid.gmane.org/87wqea7c37.fsf@nikula.org

Exactly!

> 
>> I took the liberty of making the first move by
>> creating https://github.com/notmuch and splitting the contrib/ and binding/
>> into their own repository (conserving all their history).
> 
> I am concerned people will mistake that for the official notmuch
> repository.

Me too! I am just a (happy) user here, but I do know that the sort
of confusion that might arise can work against acceptance of a piece
of software. I think that doing this without waiting for feedback,
especially from the people who do most of the work on notmuch, is
somewhat high-handed.

Eric
-- 
ms fnd in a lbry

Re: Github?

[Guyzmo]

Hi,

On Thu, May 08, 2014 at 09:40:45AM +0100, Eric wrote:
> On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula <jani@nikula.org> wrote:
> > On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com> wrote:
[...]
> >> Any thoughts on moving to Github?
> > http://mid.gmane.org/87wqea7c37.fsf@nikula.org
> Exactly!

it feels like there's an echo in the room ;-)

> >> I took the liberty of making the first move by
> >> creating https://github.com/notmuch and splitting the contrib/ and binding/
> >> into their own repository (conserving all their history).
> > I am concerned people will mistake that for the official notmuch
> > repository.
> Me too! I am just a (happy) user here, but I do know that the sort
> of confusion that might arise can work against acceptance of a piece
> of software. I think that doing this without waiting for feedback,
> especially from the people who do most of the work on notmuch, is
> somewhat high-handed.

    well, because of git's fundamental feature to be distributed,  I see
no reason why notmuch couldn't have a *mirror* on github, as well  as on
gitorious or bitbucket. As long as the description says explicitly:

*mirror of the http://git.notmuchmail.org/git/notmuch repository*

    and that the README.md starts by giving where the official  repo is,
and explains how to submit patches. And *always* refuse to merge in pull
requests. A good thing would be to have it  automatically  kept  in sync
with the original repository, and a nice way to do it would be to create
a post-receive hook on the principal repository.

    As a nice  side  effect  of  doing  this,  we'll  stop  having users
complain  about  "not  being  on  github"...  Even  though  they  should
understand that this is github that has a design flaw not being  able to
track forks coming from outside of github, or getting out of github.

my 2 cents,

-- 
Guyzmo

Re: Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

Hi everyone,

I didn't see the previous email about it, thank you Jani for the link. It
looks like you guys have your hands full and everything setup the way you
like it, so here's what I'll do myself (if it's acceptable with you,
otherwise I'll just remove everything):

- Revert my changes (except for the CI)
- Set a cron job to update the mirror hourly for the Github user wanting to
fork.
- Remove the Issues, Pull Request and the Wiki
- Add a "mirror of .." to the description on top of the page
- Manually update the contrib/ bindings/ as they change in here and maybe
automate it later.

For the automatic pusher, I'll have to skip the README changes.

Wael

On Thu May 08 2014 at 3:16:29 AM, Guyzmo <guyzmo+notmuch@m0g.net> wrote:

> Hi,
>
> On Thu, May 08, 2014 at 09:40:45AM +0100, Eric wrote:
> > On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula <jani@nikula.org> wrote:
> > > On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com>
> wrote:
> [...]
> > >> Any thoughts on moving to Github?
> > > http://mid.gmane.org/87wqea7c37.fsf@nikula.org
> > Exactly!
>
> it feels like there's an echo in the room ;-)
>
> > >> I took the liberty of making the first move by
> > >> creating https://github.com/notmuch and splitting the contrib/ and
> binding/
> > >> into their own repository (conserving all their history).
> > > I am concerned people will mistake that for the official notmuch
> > > repository.
> > Me too! I am just a (happy) user here, but I do know that the sort
> > of confusion that might arise can work against acceptance of a piece
> > of software. I think that doing this without waiting for feedback,
> > especially from the people who do most of the work on notmuch, is
> > somewhat high-handed.
>
>     well, because of git's fundamental feature to be distributed,  I see
> no reason why notmuch couldn't have a *mirror* on github, as well  as on
> gitorious or bitbucket. As long as the description says explicitly:
>
> *mirror of the http://git.notmuchmail.org/git/notmuch repository*
>
>     and that the README.md starts by giving where the official  repo is,
> and explains how to submit patches. And *always* refuse to merge in pull
> requests. A good thing would be to have it  automatically  kept  in sync
> with the original repository, and a nice way to do it would be to create
> a post-receive hook on the principal repository.
>
>     As a nice  side  effect  of  doing  this,  we'll  stop  having users
> complain  about  "not  being  on  github"...  Even  though  they  should
> understand that this is github that has a design flaw not being  able to
> track forks coming from outside of github, or getting out of github.
>
> my 2 cents,
>
> --
> Guyzmo
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]

Re: Github?

[Wael M. Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
<wael.nasreddine@gmail.com>wrote:

> Hi everyone,
>
> I didn't see the previous email about it, thank you Jani for the link. It
> looks like you guys have your hands full and everything setup the way you
> like it, so here's what I'll do myself (if it's acceptable with you,
> otherwise I'll just remove everything):
>
> - Revert my changes (except for the CI)
> - Set a cron job to update the mirror hourly for the Github user wanting
> to fork.
> - Remove the Issues, Pull Request and the Wiki
> - Add a "mirror of .." to the description on top of the page
> - Manually update the contrib/ bindings/ as they change in here and maybe
> automate it later.
>

Can you guys at least consider splitting contrib/ and bindings/ into their
own repo? It will make it easier for people to use the go bindings (for
example) or to include the vim plugin as a submodule (or Vundle bundle).


>
> For the automatic pusher, I'll have to skip the README changes.
>
> Wael
>
>
> On Thu May 08 2014 at 3:16:29 AM, Guyzmo <guyzmo+notmuch@m0g.net> wrote:
>
>> Hi,
>>
>> On Thu, May 08, 2014 at 09:40:45AM +0100, Eric wrote:
>> > On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula <jani@nikula.org>
>> wrote:
>> > > On Thu, 08 May 2014, Wael Nasreddine <wael.nasreddine@gmail.com>
>> wrote:
>> [...]
>> > >> Any thoughts on moving to Github?
>> > > http://mid.gmane.org/87wqea7c37.fsf@nikula.org
>> > Exactly!
>>
>> it feels like there's an echo in the room ;-)
>>
>> > >> I took the liberty of making the first move by
>> > >> creating https://github.com/notmuch and splitting the contrib/ and
>> binding/
>> > >> into their own repository (conserving all their history).
>> > > I am concerned people will mistake that for the official notmuch
>> > > repository.
>> > Me too! I am just a (happy) user here, but I do know that the sort
>> > of confusion that might arise can work against acceptance of a piece
>> > of software. I think that doing this without waiting for feedback,
>> > especially from the people who do most of the work on notmuch, is
>> > somewhat high-handed.
>>
>>     well, because of git's fundamental feature to be distributed,  I see
>> no reason why notmuch couldn't have a *mirror* on github, as well  as on
>> gitorious or bitbucket. As long as the description says explicitly:
>>
>> *mirror of the http://git.notmuchmail.org/git/notmuch repository*
>>
>>     and that the README.md starts by giving where the official  repo is,
>> and explains how to submit patches. And *always* refuse to merge in pull
>> requests. A good thing would be to have it  automatically  kept  in sync
>> with the original repository, and a nice way to do it would be to create
>> a post-receive hook on the principal repository.
>>
>>     As a nice  side  effect  of  doing  this,  we'll  stop  having users
>> complain  about  "not  being  on  github"...  Even  though  they  should
>> understand that this is github that has a design flaw not being  able to
>> track forks coming from outside of github, or getting out of github.
>>
>> my 2 cents,
>>
>> --
>> Guyzmo
>> _______________________________________________
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>>
>


-- 
Wael Nasreddine | Software Engineer |  wael.nasreddine@gmail.com |  (650)
735-1773

[-- Attachment #2: Type: text/html, Size: 5964 bytes --]

Re: Github?

[Felipe Contreras]

Wael M. Nasreddine wrote:
> Can you guys at least consider splitting contrib/ and bindings/ into
> their own repo?

It don't think that's such a good idea. One of the reasons Notmuch and
other projects like the Linux kernel have everything under one tree is
that changes in the API can be done across the board.

Sure, nowadays Notmuch has much more stable API, so that might not be
such a big deal, but changes in the API do still happen, and they do,
it's important to keep all the bindings aligned.

Maybe splitting 'contrib/' wouldn't be such a bad idea, if we mentioned
these tools in the web site, as a way of propoting them.

> It will make it easier for people to use the go bindings (for
> example) or to include the vim plugin as a submodule (or Vundle bundle).

I'm not sure about the Go bindings, but as a user of the Ruby bindings,
I find it easier for Notmuch to distribute them.

As for the vim plugin, it can already be used as a bundle:

https://github.com/felipec/notmuch-vim-ruby

-- 
Felipe Contreras

Re: Github?

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

On Thu, May 08, 2014 at 07:54:38PM +0000, Wael Nasreddine wrote:
> - Revert my changes (except for the CI)

I'd revert all the changes and submit them upstream, so the GitHub
repository is an exact mirror of
http://git.notmuchmail.org/git/notmuch.  A Travis-CI file is
Travis-specific, not necessarily GitHub-specific.  You could,
theoretically, run your own Travis without involving GitHub at all
[1].  Since there's already automated testing with buildbot [1], I
doubt the travis patch will land in master, but you never know.
However, none of this stops you from having your own fork of notmuch
with the travis patch in it, and you can use cron jobs or whatever to
merge with the upstream master as often as you like.

> - Add a "mirror of .." to the description on top of the page

Looks like this is already there.

> - Manually update the contrib/ bindings/ as they change in here and maybe
> automate it later.

With an exact mirror, adding a post-update hook that pushes from
git.notmuchmail.org/git/* to the appropriate GitHub repo should be
easy.  GitHub does this internally for Emacs, GCC, etc. [3,4], but
we'd probably have to do it by hand for notmuch.

> - Remove the Issues, Pull Request and the Wiki

Adding a note directing folks to the mailing list would probably also
be useful.

Cheers,
Trevor

[1]: https://github.com/travis-ci/travis-ci
     I haven't looked through all of these packages, maybe they're not
     all open source, or maybe there are closed-source pieces missing.
     Still, it looks like a lot of Travis is open source.
[2]: http://buildbot.notmuchmail.org/grid
[3]: https://help.github.com/articles/about-official-github-mirrors
[4]: https://github.com/mirrors

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[Suvayu Ali]

Hi,

Disclaimer: I'm not a developer, just a user who follows the list.

On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
> On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
> <wael.nasreddine@gmail.com>wrote:
> 
> > Hi everyone,
> >
> > I didn't see the previous email about it, thank you Jani for the link. It
> > looks like you guys have your hands full and everything setup the way you
> > like it, so here's what I'll do myself (if it's acceptable with you,
> > otherwise I'll just remove everything):
> >
> > - Revert my changes (except for the CI)
> > - Set a cron job to update the mirror hourly for the Github user wanting
> > to fork.
> > - Remove the Issues, Pull Request and the Wiki
> > - Add a "mirror of .." to the description on top of the page
> > - Manually update the contrib/ bindings/ as they change in here and maybe
> > automate it later.
> >
> 
> Can you guys at least consider splitting contrib/ and bindings/ into their
> own repo? It will make it easier for people to use the go bindings (for
> example) or to include the vim plugin as a submodule (or Vundle bundle).

What is the problem if contrib and bindings are part of the main repo?
In fact I would argue it is undesirable to split them.  If there are
major changes in libnotmuch, or the cli, it is much easier to make the
corresponding changes in bindings to keep everything working.  If there
is a separate repo, communicating this dependency, although not
impossible, is difficult.  I would also like to point out almost all
FOSS projects I follow, or contribute to practises this.

Just my 2¢.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Github?

[guyzmo]

On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote:
> On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
> > On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
> > <wael.nasreddine@gmail.com>wrote:
[...]
> > Can you guys at least consider splitting contrib/ and bindings/ into their
> > own repo? It will make it easier for people to use the go bindings (for
> > example) or to include the vim plugin as a submodule (or Vundle bundle).
> 
> What is the problem if contrib and bindings are part of the main repo?
> In fact I would argue it is undesirable to split them.  If there are
> major changes in libnotmuch, or the cli, it is much easier to make the
> corresponding changes in bindings to keep everything working.  If there
> is a separate repo, communicating this dependency, although not
> impossible, is difficult.  I would also like to point out almost all
> FOSS projects I follow, or contribute to practises this.

    do you know about git submodules? It's actually there to be  able to
track changes on remote repositories  that  are  closely  related, while
keeping a sane separation.

N.B.: the downside of something like notmuch, it's that it's making it a
pleasure again to write and check mails, and thus it's easy  to  ends up
discussing trivialities that can end up in endless trolls.

my 2 cts as well,

-- 
Guyzmo

Re: Github?

[Suvayu Ali]

On Thu, May 08, 2014 at 11:21:00PM +0200, guyzmo wrote:
> On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
> > > On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
> > > <wael.nasreddine@gmail.com>wrote:
> [...]
> > > Can you guys at least consider splitting contrib/ and bindings/ into their
> > > own repo? It will make it easier for people to use the go bindings (for
> > > example) or to include the vim plugin as a submodule (or Vundle bundle).
> > 
> > What is the problem if contrib and bindings are part of the main repo?
> > In fact I would argue it is undesirable to split them.  If there are
> > major changes in libnotmuch, or the cli, it is much easier to make the
> > corresponding changes in bindings to keep everything working.  If there
> > is a separate repo, communicating this dependency, although not
> > impossible, is difficult.  I would also like to point out almost all
> > FOSS projects I follow, or contribute to practises this.
> 
>     do you know about git submodules? It's actually there to be  able to
> track changes on remote repositories  that  are  closely  related, while
> keeping a sane separation.

I do, hence the "although not impossible".  It's still adding complexity
that is not needed for something like language bindings.  

What is so hard to package them when part of the project repo?  In fact,
I package notmuch along with its python bindings and a few utilities
from contrib for Fedora[1].  The default Fedora packages are horribly
outdated.  One of my TODOs is to also package the ruby bindings, and
notmuch-vim.  The only thing preventing me now is my unfamiliarty with
ruby, and Fedora packaging guidelines for ruby-gems.

Footnotes:

[1] http://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-20-x86_64/notmuch-0.18-5.20140506.git.8ecc7db3.fc20/


-- 
Suvayu

Open source is the future. It sets us free.

Submodules for language bindings (was: Github?)

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> One of my TODOs is to also package the ruby bindings, and
> notmuch-vim.  The only thing preventing me now is my unfamiliarty
> with ruby, and Fedora packaging guidelines for ruby-gems.

I think this is one argument argument in favor of submodules, because
they make it easy to treat the bindings as separate packages.  Once
you have separate packages, it's easy to delegate packaging (e.g. “I
don't use the Ruby bindings, so I'm not going to maintain the
Ruby-binding package.  I'll leave that to Alice, who likes Ruby, but
is less familiar with $distro's Python packaging”).

Of course, you can have separate binding packages (if you like)
without having separate per-binding repositories (or branches).  I
personally like the looser coupling of submodules (and the ability to
easily delegate maintainer-ship), but I don't see any notmuch-binding
work in my future, so I don't mind either way.  Consider this an “I
like submodules for this sort of thing” post more than a “notmuch
should use submodules” post ;).

Cheers,
Trevor

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[David Bremner]

Wael Nasreddine <wael.nasreddine@gmail.com> writes:

> I didn't see the previous email about it, thank you Jani for the link. It
> looks like you guys have your hands full and everything setup the way you
> like it, so here's what I'll do myself (if it's acceptable with you,
> otherwise I'll just remove everything):
>
> - Revert my changes (except for the CI)
> - Set a cron job to update the mirror hourly for the Github user wanting to
> fork.
> - Remove the Issues, Pull Request and the Wiki
> - Add a "mirror of .." to the description on top of the page
> - Manually update the contrib/ bindings/ as they change in here and maybe
> automate it later.
>
> For the automatic pusher, I'll have to skip the README changes.

I think the concensus among the devs is that if there is going to be a
"notmuch" organization on github then it should be owned by and
controlled by us.

I'm sure your intentions are good, but reasonable people can differ
about the best way to do things; in particular it makes no sense to me have
a mirror where the history has been rewritten, meaning that people can't
merge to or from the offical repo.

Of course what you do as your own github user is up to you.

d

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > One of my TODOs is to also package the ruby bindings, and
> > notmuch-vim.  The only thing preventing me now is my unfamiliarty
> > with ruby, and Fedora packaging guidelines for ruby-gems.
> 
> I think this is one argument argument in favor of submodules, because
> they make it easy to treat the bindings as separate packages.  Once
> you have separate packages, it's easy to delegate packaging (e.g. “I
> don't use the Ruby bindings, so I'm not going to maintain the
> Ruby-binding package.  I'll leave that to Alice, who likes Ruby, but
> is less familiar with $distro's Python packaging”).

Well as far as my understanding of rpm goes, sub-packages are prefered
here rather than independent packages.  I believe the reason is again
easier dependency tracking[1]; all sub-packages share the same source
rpm, so no explicit `Requires' in the spec file.

Cheers,

Footnotes:

[1] yum and it's ilk don't do that by magic, the packager needs to add
    instructions in the spec file for that to work correctly.  With
    sub-packages, this becomes redundant.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

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 :)

On Thursday, May 8, 2014 3:42:05 PM, David Bremner <david@tethera.net>
wrote:

> Wael Nasreddine <wael.nasreddine@gmail.com> writes:
>
> > I didn't see the previous email about it, thank you Jani for the link. It
> > looks like you guys have your hands full and everything setup the way you
> > like it, so here's what I'll do myself (if it's acceptable with you,
> > otherwise I'll just remove everything):
> >
> > - Revert my changes (except for the CI)
> > - Set a cron job to update the mirror hourly for the Github user wanting
> to
> > fork.
> > - Remove the Issues, Pull Request and the Wiki
> > - Add a "mirror of .." to the description on top of the page
> > - Manually update the contrib/ bindings/ as they change in here and maybe
> > automate it later.
> >
> > For the automatic pusher, I'll have to skip the README changes.
>
> I think the concensus among the devs is that if there is going to be a
> "notmuch" organization on github then it should be owned by and
> controlled by us.
>
> I'm sure your intentions are good, but reasonable people can differ
> about the best way to do things; in particular it makes no sense to me have
> a mirror where the history has been rewritten, meaning that people can't
> merge to or from the offical repo.
>
> Of course what you do as your own github user is up to you.
>
> d
>
>

[-- Attachment #2: Type: text/html, Size: 2040 bytes --]

Re: Github?

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

David Bremner <david@tethera.net> writes:

> Wael Nasreddine <wael.nasreddine@gmail.com> writes:
>
>> I didn't see the previous email about it, thank you Jani for the link. It
>> looks like you guys have your hands full and everything setup the way you
>> like it, so here's what I'll do myself (if it's acceptable with you,
>> otherwise I'll just remove everything):
>>
>> - Revert my changes (except for the CI)
>> - Set a cron job to update the mirror hourly for the Github user wanting to
>> fork.
>> - Remove the Issues, Pull Request and the Wiki
>> - Add a "mirror of .." to the description on top of the page
>> - Manually update the contrib/ bindings/ as they change in here and maybe
>> automate it later.
>>
>> For the automatic pusher, I'll have to skip the README changes.
>
> I think the concensus among the devs is that if there is going to be a
> "notmuch" organization on github then it should be owned by and
> controlled by us.
>

Let me expand on that comment a bit.  It's great that you want to run a
CI instance (we already have one, but who knows, maybe this will catch
some problems our current instance does not).  It's also fine that you
want to run a mirror, or even (obviously) distribute modified versions
of notmuch.  The main point that many of us are sensitive about is
people confusing these modified versions (and yeah, I consider splitting
the repo modification) with the official one. The other point is that by
admining the "notmuch" project on github, you are somehow officially
representing the project to the outside world. Maybe if we get to know
you, and we develop the appropriate communications channels, we'd think
that would be a great idea, but it seems like too much to entrust to
somebody we just "met".

d



[-- Attachment #2: Type: application/pgp-signature, Size: 647 bytes --]

Re: Submodules for language bindings (was: Github?)

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > One of my TODOs is to also package the ruby bindings, and
> > > notmuch-vim.  The only thing preventing me now is my
> > > unfamiliarty with ruby, and Fedora packaging guidelines for
> > > ruby-gems.
> > 
> > I think this is one argument argument in favor of submodules,
> > because they make it easy to treat the bindings as separate
> > packages.  Once you have separate packages, it's easy to delegate
> > packaging (e.g. “I don't use the Ruby bindings, so I'm not going
> > to maintain the Ruby-binding package.  I'll leave that to Alice,
> > who likes Ruby, but is less familiar with $distro's Python
> > packaging”).
> 
> Well as far as my understanding of rpm goes, sub-packages are
> prefered here rather than independent packages.  I believe the
> reason is again easier dependency tracking[1]; all sub-packages
> share the same source rpm, so no explicit `Requires' in the spec
> file.

It looks like sub-packages share a single spec file with the main
package [1].  That means you'll have to have authors with the full
range of binding-language expertise to bump that spec file (assuming
there are any changes that require bumps).  For example, Gentoo's
Python eclasses have gone through a few revisions in the last year or
two, and I wouldn't expect one person to stay on top of the latest
packaging styles for every language with notmuch bindings.  I think
the benefit of having separate packages (and spec files, or ebuilds,
or whatever) is that you can release notmuch-0.18 without worrying
about all those bindings, and leave it to the other maintainers (who
might include you) to independently package notmuch-python-0.18,
notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of
bindings, it doesn't really matter, but I think you'll want the weaker
coupling of stand-alone packages by the time you hit a dozen
languages.  “Bump an explicit 'Requires'” certainly seems like a lower
barrier than “package Go bindings idiomatically for Fedora” ;).

Cheers,
Trevor

[1]: http://www.rpm.org/max-rpm/ch-rpm-subpack.html

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

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/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

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/Pretty_Good_Privacy
>

[-- Attachment #2: Type: text/html, Size: 3234 bytes --]

Re: Github?

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Fri, May 09, 2014 at 12:13:51AM +0000, Wael Nasreddine wrote:
> 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

Those both sound good to me [1].

> Would you be willing to add Travis.yml upstream?

I'm agnostic on .Travis.yml, but the appropriate approach—since you
already have a patch—is to mail it to the list [2] :).  Then it can
get all the usual tags [3], nmbug listings [4], and review in its own
thread.

Cheers,
Trevor

[1]: But take my opinions with a grain of salt, because I'm just an
     occasional contributor and certainly not a core developer.
[2]: http://notmuchmail.org/contributing/#index11h2
[3]: "Tagging conventions" on http://notmuchmail.org/nmbug/
[4]: http://nmbug.tethera.net/status/

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[Felipe Contreras]

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 actually think we should have GitHub repo, and a .travis.yml file.
However, the travis stuff can live in a 'travis-ci' branch.

-- 
Felipe Contreras

Re: Github?

[Felipe Contreras]

W. Trevor King 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

That wouldn't be a problem if HEAD didn't point to 'master' but to
'upstream' which would be 'notmuch/master'.

Or if the branch with the modifications was called something else, like
'travis-ci'.

-- 
Felipe Contreras

Re: Github?

[Felipe Contreras]

Wael Nasreddine wrote:
> Would you be willing to add Travis.yml upstream?

I would. After all we have packaging stuff which are not strictly part
of notmuch.

-- 
Felipe Contreras

Re: Github?

[Felipe Contreras]

guyzmo wrote:
> do you know about git submodules? It's actually there to be  able to
> track changes on remote repositories  that  are  closely  related,
> while keeping a sane separation.

Git sumobules are more like a hack than an integral part of Git. I
personally avoid them like the plague.

Source: I'm a Git developer.

-- 
Felipe Contreras

Re: Github?

[Felipe Contreras]

Wael Nasreddine wrote:
> Actually you can't have the .Travis.yml file in a separate branch,
> Travis require it present in the context that it is testing (commits
> to all branches)

Yes, so? The 'travis-ci' branch can merge from upstream, and then
upstream would be tested.

-- 
Felipe Contreras

Re: Github?

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Actually you can't have the .Travis.yml file in a separate branch, Travis
require it present in the context that it is testing (commits to all
branches)

On Thursday, May 8, 2014 7:53:52 PM, Felipe Contreras <
felipe.contreras@gmail.com> wrote:

> W. Trevor King 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
>
> That wouldn't be a problem if HEAD didn't point to 'master' but to
> 'upstream' which would be 'notmuch/master'.
>
> Or if the branch with the modifications was called something else, like
> 'travis-ci'.
>
> --
> Felipe Contreras

[-- Attachment #2: Type: text/html, Size: 1860 bytes --]

Re: Github?

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Thu, May 08, 2014 at 09:43:01PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > 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…
> 
> That wouldn't be a problem if HEAD didn't point to 'master' but to
> 'upstream' which would be 'notmuch/master'.
> 
> Or if the branch with the modifications was called something else,
> like 'travis-ci'.

Agreed.  The only problem I'd have is that you'd want to say that the
GitHub repo was a mirror, since the primary repo would still be
git://notmuchmail.org/git/notmuch.  If it's a mirror, I think it
should mirror all refs on the main repo [1] without adding new ones.
I'm happy for 'travis-ci' branches and whatnot in repositories that
don't claim to mirror the notmuchmail.org repo.  I'm also happy to
have the Travis config upstream (in any branch), in which case it
would show up in the mirror.  I just don't think it's a good idea to
have tweaks on a “mirror” that aren't upstream, even if it doesn't
effect any upstream refs.

Cheers,
Trevor

[1]: in the style of 'git clone --mirror …'

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Github?

[Felipe Contreras]

W. Trevor King wrote:
> Agreed.  The only problem I'd have is that you'd want to say that the
> GitHub repo was a mirror, since the primary repo would still be
> git://notmuchmail.org/git/notmuch.  If it's a mirror, I think it
> should mirror all refs on the main repo [1] without adding new ones.

I disagree. There's absolutely zero chance of a problem adding a
'travis-ci' branch, which adds a single file, which would conflict with
upstream in anyway.

-- 
Felipe Contreras

Re: Github?

[Douglas Campos]

On Thu, May 08, 2014 at 08:01:56PM -0700, W. Trevor King wrote:
> Agreed.  The only problem I'd have is that you'd want to say that the
> GitHub repo was a mirror, since the primary repo would still be
> git://notmuchmail.org/git/notmuch.  If it's a mirror, I think it
> should mirror all refs on the main repo [1] without adding new ones.
> I'm happy for 'travis-ci' branches and whatnot in repositories that
> don't claim to mirror the notmuchmail.org repo.  I'm also happy to
> have the Travis config upstream (in any branch), in which case it
> would show up in the mirror.  I just don't think it's a good idea to
> have tweaks on a “mirror” that aren't upstream, even if it doesn't
> effect any upstream refs.

Then just email support@github.com and I'm sure they will be happy to
setup the repo as a mirror like they've did for some apache projects
like cordova[1].


[1]:https://github.com/apache/cordova-cli

-- 
qmx

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

Hi Trevor,

On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > > One of my TODOs is to also package the ruby bindings, and
> > > > notmuch-vim.  The only thing preventing me now is my
> > > > unfamiliarty with ruby, and Fedora packaging guidelines for
> > > > ruby-gems.
> > > 
> > > I think this is one argument argument in favor of submodules,
> > > because they make it easy to treat the bindings as separate
> > > packages.  Once you have separate packages, it's easy to delegate
> > > packaging (e.g. “I don't use the Ruby bindings, so I'm not going
> > > to maintain the Ruby-binding package.  I'll leave that to Alice,
> > > who likes Ruby, but is less familiar with $distro's Python
> > > packaging”).
> > 
> > Well as far as my understanding of rpm goes, sub-packages are
> > prefered here rather than independent packages.  I believe the
> > reason is again easier dependency tracking[1]; all sub-packages
> > share the same source rpm, so no explicit `Requires' in the spec
> > file.
> 
> It looks like sub-packages share a single spec file with the main
> package [1].  That means you'll have to have authors with the full
> range of binding-language expertise to bump that spec file (assuming
> there are any changes that require bumps).  For example, Gentoo's
> Python eclasses have gone through a few revisions in the last year or
> two, and I wouldn't expect one person to stay on top of the latest
> packaging styles for every language with notmuch bindings.  I think
> the benefit of having separate packages (and spec files, or ebuilds,
> or whatever) is that you can release notmuch-0.18 without worrying
> about all those bindings, and leave it to the other maintainers (who
> might include you) to independently package notmuch-python-0.18,
> notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of
> bindings, it doesn't really matter, but I think you'll want the weaker
> coupling of stand-alone packages by the time you hit a dozen
> languages.  “Bump an explicit 'Requires'” certainly seems like a lower
> barrier than “package Go bindings idiomatically for Fedora” ;).

You have a point, however I would still disagree.  You seem to use
Gentoo, and I think what you say works better for Gentoo because it is a
source distribution.  For binary distributions, this is a bit harder
(and limiting).  To explain my point with RPM specifics, if I were to
use separate spec files, python-notmuch would have:

  Requires: notmuch >= <version-string>

As you can see this only allows for tracking dependency based on
official version numbers.  With more bindings, many with different
version dependencies, this becomes quite cumbersome; more so when you
are doing snapshots (as I do for my repo[1]).  As a packager, I think I
would prefer to learn different packaging guidelines, setup my spec file
and forget about it rather than continually follow all changes.  But I
guess this is where you would argue with different responsible people, I
would not have to do all the thinking :-p.

Anyway, whichever way the devs choose to go, I (and other packagers)
will adapt.

Cheers,


Footnotes:

[1] I would love to know if anyone here uses it.  I announced it here
    when I started it, but for all I know I could be the only user!  :-p

-- 
Suvayu

Open source is the future. It sets us free.

Re: Github?

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Hi,

Wael Nasreddine <wael.nasreddine@gmail.com> writes:

> I was a bit disappointed that the project is not living (or at least
> mirrored) to Github, it would have made my search much easier.

How GitHub would help with this? I believe that most of search engines
reach Notmuch home page.

GitHub is not the center of the world.  I have a GitHub account, too and
I use it to host some stuff, but I have never given a single thought
about encouraging project I use or contribute to to move/mirror on
GitHub just because I use it.

The same goes for Travis. There's already a build bot.  Why bother with
Travis?

I wonder when a next person is going to be _disappointed_ that there's
no mirror on Bitbucket, or that he/she couldn't find Notmuch on
Facebook/Google+/whatever... This can be a never ending story.


Just my 0.02 PLN.


Best regards,

-- 
Amadeusz Żołnowski

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: Github?

[Felipe Contreras]

Amadeusz Żołnowski wrote:
> The same goes for Travis. There's already a build bot.  Why bother
> with Travis?

I've never seen any buildbot results. TravisCI's interface is just
simple and easy. And all it requires is one file.

-- 
Felipe Contreras

Re: Submodules for language bindings (was: Github?)

[Felipe Contreras]

Suvayu Ali wrote:
> You have a point, however I would still disagree.  You seem to use
> Gentoo, and I think what you say works better for Gentoo because it is
> a source distribution.  For binary distributions, this is a bit harder
> (and limiting).

No, it's not harder.

> To explain my point with RPM specifics, if I were to
> use separate spec files, python-notmuch would have:
> 
>   Requires: notmuch >= <version-string>
> 
> As you can see this only allows for tracking dependency based on
> official version numbers.  With more bindings, many with different
> version dependencies, this becomes quite cumbersome;

No, it doesn't:

  %package notmuch-ruby
  Requires: notmuch = %{version}-%{release}, ruby

-- 
Felipe Contreras

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> Suvayu Ali wrote:
> 
> > To explain my point with RPM specifics, if I were to
> > use separate spec files, python-notmuch would have:
> > 
> >   Requires: notmuch >= <version-string>
> > 
> > As you can see this only allows for tracking dependency based on
> > official version numbers.  With more bindings, many with different
> > version dependencies, this becomes quite cumbersome;
> 
> No, it doesn't:
> 
>   %package notmuch-ruby
>   Requires: notmuch = %{version}-%{release}, ruby

Doesn't that work when you have one spec file for all sub-packages (as I
do now)?  I was responding to Trevor's suggestion about not having
sub-packages, IOW, different spec files for different packages.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Submodules for language bindings (was: Github?)

[Felipe Contreras]

Suvayu Ali wrote:
> On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> > Suvayu Ali wrote:
> > 
> > > To explain my point with RPM specifics, if I were to
> > > use separate spec files, python-notmuch would have:
> > > 
> > >   Requires: notmuch >= <version-string>
> > > 
> > > As you can see this only allows for tracking dependency based on
> > > official version numbers.  With more bindings, many with different
> > > version dependencies, this becomes quite cumbersome;
> > 
> > No, it doesn't:
> > 
> >   %package notmuch-ruby
> >   Requires: notmuch = %{version}-%{release}, ruby
> 
> Doesn't that work when you have one spec file for all sub-packages (as I
> do now)?  I was responding to Trevor's suggestion about not having
> sub-packages, IOW, different spec files for different packages.

Ah. I don't see why anybody would want different spec files for
different subpackages.

-- 
Felipe Contreras

Re: Github?

[David Bremner]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Amadeusz Żołnowski wrote:
>> The same goes for Travis. There's already a build bot.  Why bother
>> with Travis?
>
> I've never seen any buildbot results. TravisCI's interface is just
> simple and easy. And all it requires is one file.
>

Not to take a position on travis at the moment, but just to point out
that buildbot results go to #notmuch on freenode irc.

d

Re: Github?

[Wael M. Nasreddine]

On Fri, May 9, 2014 at 6:21 PM, David Bremner <david@tethera.net> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Amadeusz Żołnowski wrote:
>>> The same goes for Travis. There's already a build bot.  Why bother
>>> with Travis?
>>
>> I've never seen any buildbot results. TravisCI's interface is just
>> simple and easy. And all it requires is one file.
>>
>
> Not to take a position on travis at the moment, but just to point out
> that buildbot results go to #notmuch on freenode irc.
>

If you check out my latest patch that I sent, Travis also send
notification to both this list and IRC but only on failures or change
(failed to pass), please discuss on that thread
if this is not desired.

> d



-- 
Wael Nasreddine | Software Engineer | wael.nasreddine@gmail.com | (650) 735-1773

Re: Github?

[Tomi Ollila]

On Sat, May 10 2014, "Wael M. Nasreddine" <wael.nasreddine@gmail.com> wrote:

> On Fri, May 9, 2014 at 6:21 PM, David Bremner <david@tethera.net> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Amadeusz Żołnowski wrote:
>>>> The same goes for Travis. There's already a build bot.  Why bother
>>>> with Travis?
>>>
>>> I've never seen any buildbot results. TravisCI's interface is just
>>> simple and easy. And all it requires is one file.
>>>
>>
>> Not to take a position on travis at the moment, but just to point out
>> that buildbot results go to #notmuch on freenode irc.
>>
>
> If you check out my latest patch that I sent, Travis also send
> notification to both this list and IRC but only on failures or change
> (failed to pass), please discuss on that thread
> if this is not desired.

$ notmuch search --output=files id:1399645162-8653-1-git-send-email-wael.nasreddine@gmail.com
/home/too/mail/received/37/89c5f0b877c9146adc3d5d8c4a4004
/home/too/mail/received/f4/0c687f1918ad81a58f7571b5109587

Meaning notmuch users generally don't see the second email...

BTW: does .travis.yml support comment lines ?


Tomi

Re: Github?

[Felipe Contreras]

Tomi Ollila wrote:
> BTW: does .travis.yml support comment lines ?

It's YAML. So, yes.

-- 
Felipe Contreras