Re: GitHub + notmuch scripts/hacks

[William Casarin]

William Casarin  writes:

> I've started collecting[1] a bunch of notmuch+GitHub hacks from some of
> the discussions @ id:87d16jtsdj@kyleam.com
> [..]
>
> [1] https://github.com/jb55/notmuch-github
> [2] 
> https://github.com/jb55/notmuch-github/commit/fb2d80cf9ee9a5967c78ae6ccda866ee98cdd547
> [3] https://jb55.com/s/notmuch-github.mp4

Hey notmuch peoples,

I've started looking into possible ways to tag github pull requests and
issues. So far I've been able to put together these semi-reliable
tagging methods for pull requests:

notmuch tag +github from:github.com and tag:inbox

notmuch tag +pr '"You can view, comment on, or merge this pull request 
online at"' \
  and tag:github and not tag:pr and tag:inbox and not tag:issue

# tag all messages in the thread that have a pr tag
notmuch tag +pr $(notmuch search --output=threads tag:pr and tag:inbox)

# this seems to be a semi reliable way to find github merge emails
notmuch tag +merged Merged and event from:notificati...@github.com \
  and not tag:merged and tag:inbox and tag:pr

# tag the entire pr thread as merged
notmuch tag +merged $(notmuch search --output=threads tag:merged and 
tag:inbox)

I still haven't found a reliable way to tag issues and their closed
status. If anyone has something more reliable feel free to share here or
at https://github.com/jb55/notmuch-github#tagging

Cheers,
Will


--
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

GitHub + notmuch scripts/hacks

[William Casarin]

Hey there,

I've started collecting[1] a bunch of notmuch+GitHub hacks from some of
the discussions @ id:87d16jtsdj@kyleam.com

I've added the ability to comment on/approve/reject pull requests from a
GitHub pull-request email[2].

It can also open a magit-log view of the PR from an email, as shown in
this[3] demo video.

This is still very much a work in progress and is not very user friendly
yet. If you would like to help out and convert my hacky bash script to
elisp that would be great.

Much of this work is due to Kyle Meyer and I have been building off of it.
Thanks Kyle!

Cheers,
William


[1] https://github.com/jb55/notmuch-github
[2] 
https://github.com/jb55/notmuch-github/commit/fb2d80cf9ee9a5967c78ae6ccda866ee98cdd547
[3] https://jb55.com/s/notmuch-github.mp4


-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Kyle Meyer  writes:

> Looking at what I wrote again, I'd change DONT-FETCH to FORCE-FETCH and
> then do something like
>
> (when (or force-fetch
>   (not (magit-ref-exists-p local-ref)))
>   (magit-call-git "fetch" "origin"))
>
> where local-ref is bound to "refs/pull/origin/".  That way, "git
> fetch" is only called if the ref doesn't already exist locally or when a
> prefix argument is given, which would be useful for forced updates.

Oh, good call.

>> -(magit-log (list (concat "master..refs/pull/origin/" pr)
>> +(magit-log (list (concat "origin/master..refs/pull/origin/" pr)
>
> Anyway, it's nice to see that you've been able to modify this into
> something that might be useful to you.

Indeed, thanks again.

The last piece of the puzzle is the origin/master branch isn't always
the base branch it's merging into. I believe the proper way to do this
is like so. First we add another set of refs to fetch in our .git/config:

[remote "origin"]
  fetch = +refs/pull/*/merge:refs/merge/origin/*

Now we can use this to get the base branch for the PR:

refs/merge/origin/100^..refs/pull/origin/100

Which returns the proper set of commits.


Cheers,


-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin <j...@jb55.com> writes:

> This worked pretty well, I've modified it a bit to support a generic
> github repo location which is parsed from the subject,

Great, glad you were able to tweak that test function into something
that works well with your setup.

> and origin/master instead of master:

Yep, that's better.

>  (defun km/notmuch-visit-pr-in-magit ( dont-fetch)
> @@ -39,4 +41,4 @@
>  ;; passing a more explicit refspec to the fetch call.
>  (unless dont-fetch
>(magit-call-git "fetch" "origin"))

Looking at what I wrote again, I'd change DONT-FETCH to FORCE-FETCH and
then do something like

(when (or force-fetch
  (not (magit-ref-exists-p local-ref)))
  (magit-call-git "fetch" "origin"))

where local-ref is bound to "refs/pull/origin/".  That way, "git
fetch" is only called if the ref doesn't already exist locally or when a
prefix argument is given, which would be useful for forced updates.

> -(magit-log (list (concat "master..refs/pull/origin/" pr)
> +(magit-log (list (concat "origin/master..refs/pull/origin/" pr)

Anyway, it's nice to see that you've been able to modify this into
something that might be useful to you.

-- 
Kyle
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Kyle Meyer <k...@kyleam.com> writes:

> --8<---cut here---start->8---
>
> (defun km/notmuch-github-pr-number ()
>   "Return the PR number for this message."
>   (let (pr)
> (with-current-notmuch-show-message
>  (goto-char (point-min))
>  (if (re-search-forward "https://github\\.com/.*/pull/\\([0-9]+\\)" nil t)
>  (setq pr (match-string-no-properties 1))
>(user-error "Could not find PR number")))
> pr))
>
> ;; This function could be anything that figures out the project based
> ;; on the current notmuch message.  Or, if you use projectile and
> ;; don't mind getting queried each time, it could just read a project
> ;; from `projectile-relevant-known-projects'.
> (defun km/notmuch-repo-from-message ()
>   "Return the repository that this message is associated with."
>   (let ((fname (notmuch-show-get-filename)))
> (or (and fname
>  (string-match-p "magit-list" fname)
>  "~/src/emacs/magit")
> (user-error "Could not determine repo"
>
> (defun km/notmuch-visit-pr-in-magit ( dont-fetch)
>   "Show the Magit log for this message's PR.
> If DONT-FETCH is non-nil, do not fetch first."
>   (interactive "P")
>   (let* ((pr (km/notmuch-github-pr-number))
>  (repo (km/notmuch-repo-from-message))
>  (default-directory repo))
> ;; "origin" is hard-coded below, but it could of course be
> ;; anything.  You could also have an alist that maps repo ->
> ;; remote.
> ;;
> ;; This assumes that you've added
> ;;
> ;;fetch = +refs/pull/*/head:refs/pull/origin/*
> ;;
> ;; to origin's in ".git/config".  You could drop that assumption
> ;; passing a more explicit refspec to the fetch call.
> (unless dont-fetch
>   (magit-call-git "fetch" "origin"))
> (magit-log (list (concat "master..refs/pull/origin/" pr)
> --8<---cut here---end--->8---

This worked pretty well, I've modified it a bit to support a generic
github repo location which is parsed from the subject, and origin/master
instead of master:

--- kyle1.el	2017-10-12 12:22:01.977663605 -0700
+++ kyle2.el	2017-10-12 12:24:49.644673189 -0700
@@ -14,10 +14,12 @@
 ;; from `projectile-relevant-known-projects'.
 (defun km/notmuch-repo-from-message ()
   "Return the repository that this message is associated with."
-  (let ((fname (notmuch-show-get-filename)))
-(or (and fname
- (string-match-p "magit-list" fname)
- "~/src/emacs/magit")
+  (let ((subject (notmuch-show-get-subject))
+(repo))
+(or (and subject
+ (or (and (string-match "\\([^\]]+\\)" subject 1)
+  (setq repo (match-string-no-properties 1 subject))
+  (concat "~/dev/github/" repo
 (user-error "Could not determine repo"
 
 (defun km/notmuch-visit-pr-in-magit ( dont-fetch)
@@ -39,4 +41,4 @@
 ;; passing a more explicit refspec to the fetch call.
 (unless dont-fetch
   (magit-call-git "fetch" "origin"))
-(magit-log (list (concat "master..refs/pull/origin/" pr)
+(magit-log (list (concat "origin/master..refs/pull/origin/" pr)

Cheers,
William

-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Kyle Meyer <k...@kyleam.com> writes:

> Call M-x km/notmuch-visit-pr-in-magit in a notmuch-show buffer for a
> GitHub PR, modifying km/notmuch-repo-from-message so that it returns
> the full path to the local repository.

Are you a wizard? That worked like magit. I changed
km/notmuch-visit-pr-in-magit to parse the subject via
notmuch-show-get-subject and then went from there.

Was pretty quick too.

Going to try out this workflow more tomorrow.

Thanks!
William

-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin <j...@jb55.com> writes:

> I now mainly review GitHub PRs via the patch fetching snippet you sent,
> but there's a tedious disconnect between notmuch and magit. In the above
> scenario, I would have to:
>
>   1. cd to the project
>   2. open magit
>   2. fetch
>   3. checkout the branch
>   4. start reviewing
>
> If I want to start a review on GitHub:
>
>   5. go back to the mail buffer
>   6. open the GitHub link
>   7. try to find lines where I had a comment
>   8. make comment, start review
>
> Steps 1-4 are way too long for the number of code reviews I do at work
> and on public projects.

Fair enough.  5-8 are my pain points.

> Perhaps I could write a script that quickly jump from steps 1 to 4. I
> think this would still be too slow compared to simply fetching the patch
> and having a nicer view, at least until we have full magit code reviews.
> I guess I could just wait until that's finished.

I think you could get 1-4 nearly as quick as calling the patch fetching
command.  How about something like this?

--8<-------cut here---start->8---

(defun km/notmuch-github-pr-number ()
  "Return the PR number for this message."
  (let (pr)
(with-current-notmuch-show-message
 (goto-char (point-min))
 (if (re-search-forward "https://github\\.com/.*/pull/\\([0-9]+\\)" nil t)
 (setq pr (match-string-no-properties 1))
   (user-error "Could not find PR number")))
pr))

;; This function could be anything that figures out the project based
;; on the current notmuch message.  Or, if you use projectile and
;; don't mind getting queried each time, it could just read a project
;; from `projectile-relevant-known-projects'.
(defun km/notmuch-repo-from-message ()
  "Return the repository that this message is associated with."
  (let ((fname (notmuch-show-get-filename)))
(or (and fname
 (string-match-p "magit-list" fname)
 "~/src/emacs/magit")
(user-error "Could not determine repo"

(defun km/notmuch-visit-pr-in-magit ( dont-fetch)
  "Show the Magit log for this message's PR.
If DONT-FETCH is non-nil, do not fetch first."
  (interactive "P")
  (let* ((pr (km/notmuch-github-pr-number))
 (repo (km/notmuch-repo-from-message))
 (default-directory repo))
;; "origin" is hard-coded below, but it could of course be
;; anything.  You could also have an alist that maps repo ->
;; remote.
;;
;; This assumes that you've added
;;
;;fetch = +refs/pull/*/head:refs/pull/origin/*
;;
;; to origin's in ".git/config".  You could drop that assumption
;; passing a more explicit refspec to the fetch call.
(unless dont-fetch
  (magit-call-git "fetch" "origin"))
(magit-log (list (concat "master..refs/pull/origin/" pr)
--8<---cut here---end--->8---

Call M-x km/notmuch-visit-pr-in-magit in a notmuch-show buffer for a
GitHub PR, modifying km/notmuch-repo-from-message so that it returns the
full path to the local repository.

-- 
Kyle
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Kyle Meyer <k...@kyleam.com> writes:

> However, I personally haven't felt the need for such a command.  I
> pretty frequently use the command I posted earlier in this thread to
> take a quick look at PRs, but, for anything aside from the simplest
> changes, I want to apply the commits locally to review/test.  If I
> regularly review PRs for a GitHub repo, I have
>
> fetch = +refs/pull/*/head:refs/pull/origin/*
>
> in the GitHub remote's configuration section of ".git/config".  (GitLab
> has an analogous merge request namespace.)  Then, after fetching from
> the GitHub remote, I can view the PR in Magit like I would any other
> ref.

Nice, I've been using magit-gh-pulls for this. It's a bit clunky though
so I might try this approach instead.

I now mainly review GitHub PRs via the patch fetching snippet you sent,
but there's a tedious disconnect between notmuch and magit. In the above
scenario, I would have to:

  1. cd to the project
  2. open magit
  2. fetch
  3. checkout the branch
  4. start reviewing

If I want to start a review on GitHub:

  5. go back to the mail buffer
  6. open the GitHub link
  7. try to find lines where I had a comment
  8. make comment, start review

Steps 1-4 are way too long for the number of code reviews I do at work
and on public projects. 

Perhaps I could write a script that quickly jump from steps 1 to 4. I
think this would still be too slow compared to simply fetching the patch
and having a nicer view, at least until we have full magit code reviews.
I guess I could just wait until that's finished.

> Jonas recently got a Kickstarter funded [1], and one of his goals is
> to support code review from within Magit [2]. Not sure how that will
> turn out, but it seems more promising than my current strategy of
> hoping everyone will start sharing my preference for mail-based
> collaboration :)

This is the dream. I have been following this as well. I hope Jonas can
pull it off.

Thanks for the tips!

Cheers,
William


-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin <j...@jb55.com> writes:

> I was wondering if you had any insight into what I'm thinking next. I
> would love to view these patches via the way magit handles hunks. I
> wonder if there was a way to get magit-style hunk browsing when viewing
> a patch file with a series of commits.
>
> Things like:
>
>   * Jump to the next/previous hunk/commit in a patch series

Diff mode has navigation commands to go to the next hunk/file, but not
the next commit.

>   * Collapse hunks/commits with tab

Hmm, yeah, I don't think Diff mode has commands for collapsing sections.
And I haven't checked, but I'd guess that Diff mode isn't really
recognizing the structure of the patch series; it's probably just
considering the next commit's header/message as context lines.

Magit doesn't have a mode for displaying a patch series.  Creating such
a mode shouldn't be too painful, at least if the command maps the patch
series to a local repository.

However, I personally haven't felt the need for such a command.  I
pretty frequently use the command I posted earlier in this thread to
take a quick look at PRs, but, for anything aside from the simplest
changes, I want to apply the commits locally to review/test.  If I
regularly review PRs for a GitHub repo, I have

fetch = +refs/pull/*/head:refs/pull/origin/*

in the GitHub remote's configuration section of ".git/config".  (GitLab
has an analogous merge request namespace.)  Then, after fetching from
the GitHub remote, I can view the PR in Magit like I would any other
ref.

> You get this for free with mailed patches + notmuch, but dealing with
> large patch series from GitHub is a bit annoying as it's one big buffer
> with no way to jump between commits.

I share your preference for mailed patches, but using the process above,
I don't find *viewing* GitHub PRs annoying.  I do find *reviewing*
GitHub PRs annoying and tedious compared to reviewing patches on a
mailing list.  At the moment, I typically do the review/commenting
locally and at the end open a browser and add my inline comments.

Jonas recently got a Kickstarter funded [1], and one of his goals is to
support code review from within Magit [2].  Not sure how that will turn
out, but it seems more promising than my current strategy of hoping
everyone will start sharing my preference for mail-based collaboration :)


[1] 
https://www.kickstarter.com/projects/1681258897/its-magit-the-magical-git-client
[2] https://github.com/magit/magit/issues/2972

-- 
Kyle
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Hey Kyle,

Kyle Meyer <k...@kyleam.com> writes:
>> I wonder if it would be be possible to wash this email by downloading
>> the patch and present it inline like git-send-email. This would allow me
>> to review patches without having to click around the GitHub interface.
>> Has anyone done this?
>
> I have a command in my Emacs configuration that I think gets close to
> what you want.

I was wondering if you had any insight into what I'm thinking next. I
would love to view these patches via the way magit handles hunks. I
wonder if there was a way to get magit-style hunk browsing when viewing
a patch file with a series of commits.

Things like:

  * Jump to the next/previous hunk/commit in a patch series
  * Collapse hunks/commits with tab

You get this for free with mailed patches + notmuch, but dealing with
large patch series from GitHub is a bit annoying as it's one big buffer
with no way to jump between commits.

Do you know of any mode that would make this a reality or does it not
exist yet?

Cheers,
William

-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[github-thread] find and open corresponding github page for thread or message

[Gaute Hope]

Hi,

this small script finds and opens the corresponding GitHub issue, 
comment, or pull-request. 


 https://gist.github.com/gauteh/de546cb143ebae4a489a482a05ab4beb

 $ ./github-thread.py notmuch-thread-id [message-id]

the first argument is always required. If a message id is specified, it 
first tries to scroll to that specific message.


Note: This will work more reliably on newer issues since they contain a 
nice JSON packet.


Requires: 


 * Python >= 3.3
 * Notmuch Python bindings


Regards, Gaute



pgpAt0CDPeYz4.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[William Casarin]

Kyle Meyer  writes:

> I have a command in my Emacs configuration that I think gets close to
> what you want.

This is great! Now if there was only a way to make it work for private
repositories... hmm...

-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

Tomi Ollila <tomi.oll...@iki.fi> writes:

> On Thu, Sep 21 2017, Kyle Meyer wrote:
>
>>
>> --8<---cut here---start----->8---
>> (defun km/open-github-patch (buffer)
>>   "Find GitHub patch link in BUFFER and show it in a new buffer."
>>   (let ((url
>>  (with-current-buffer buffer
>>(save-excursion
>>  (goto-char (point-min))
>>  (if (re-search-forward "https://github.com/.*\\.patch; nil t)
>
> Just a read-through thought -- would "https://github[.]com/.*[.]patch; work
> above ?

oops, good catch.  I didn't mean to match any single character with the
first period.

Either your suggestion or "https://github\\.com/.*\\.patch; should work.

-- 
Kyle
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Tomi Ollila]

On Thu, Sep 21 2017, Kyle Meyer wrote:

>
> --8<---cut here---start->8---
> (defun km/open-github-patch (buffer)
>   "Find GitHub patch link in BUFFER and show it in a new buffer."
>   (let ((url
>  (with-current-buffer buffer
>(save-excursion
>  (goto-char (point-min))
>  (if (re-search-forward "https://github.com/.*\\.patch; nil t)

Just a read-through thought -- would "https://github[.]com/.*[.]patch; work
above ?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin writes:

> Most of the patches I review these days comes in as GitHub emails that
> look like this:
>
>
> You can view, comment on, or merge this pull request online at:

[...]

> -- Patch Links --
>
> https://github.com/monstercat/iris/pull/52.patch
> https://github.com/monstercat/iris/pull/52.diff

[...]

> I wonder if it would be be possible to wash this email by downloading
> the patch and present it inline like git-send-email. This would allow me
> to review patches without having to click around the GitHub interface.
> Has anyone done this?

I have a command in my Emacs configuration that I think gets close to
what you want.

--8<---cut here---start->8---
(defun km/open-github-patch (buffer)
  "Find GitHub patch link in BUFFER and show it in a new buffer."
  (let ((url
 (with-current-buffer buffer
   (save-excursion
 (goto-char (point-min))
 (if (re-search-forward "https://github.com/.*\\.patch; nil t)
 (match-string-no-properties 0)
   (user-error "No patch found"))
(with-current-buffer (get-buffer-create
  (generate-new-buffer-name "*mail-github-patch*"))
  (url-insert-file-contents url)
  (diff-mode)
  (view-mode 1)
  (pop-to-buffer (current-buffer)

(defun km/notmuch-show-open-github-patch ()
  "Open patch from GitHub email."
  (interactive)
  (with-current-notmuch-show-message
   (km/open-github-patch (current-buffer
--8<---cut here---end--->8---

The km/open-github-patch helper function exists because I made a slow
transition from gnus to notmuch and have a gnus variant that also calls
km/open-github-patch.  If km/notmuch-show-open-github-patch is the only
caller, there's not much point in having a separate helper function.

-- 
Kyle
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Washing GitHub emails to include inline patch?

[William Casarin]

Hey team,

Most of the patches I review these days comes in as GitHub emails that
look like this:

--- Begin Message ---
You can view, comment on, or merge this pull request online at:
MIME-Version: 1.0
Content-Type: text/plain

  https://github.com/monstercat/iris/pull/52

-- Commit Summary --

  * Fix merge conflict putting location search into non-clean-ui iris

-- File Changes --

M bin/js/main.js (66)
M bin/js/users.js (71)
M html/head.html (2)
M templates/users.html (68)

-- Patch Links --

https://github.com/monstercat/iris/pull/52.patch
https://github.com/monstercat/iris/pull/52.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/monstercat/iris/pull/52
--- End Message ---


I wonder if it would be be possible to wash this email by downloading
the patch and present it inline like git-send-email. This would allow me
to review patches without having to click around the GitHub interface.
Has anyone done this?

Cheers,
William
 
-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Github an licensing

[David Bremner]

Mark Walters  writes:

>> On irc rlb pointed me to
>> https://joeyh.name/blog/entry/removing_everything_from_github/
>>
>> IANAL so I don't know whether it is a real problem, a hypothetical
>> problem or not a problem.
>
> I got a couple of links sent to me privately which look relevant:
>
>  * https://news.ycombinator.com/item?id=13767373
>  * https://news.ycombinator.com/item?id=13766933
>
> (hacker threads, but from people claiming to be lawyers)

Another comment, from the FSF


https://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Github an licensing

[Mark Walters]

> On irc rlb pointed me to
> https://joeyh.name/blog/entry/removing_everything_from_github/
>
> IANAL so I don't know whether it is a real problem, a hypothetical
> problem or not a problem.

I got a couple of links sent to me privately which look relevant:

 * https://news.ycombinator.com/item?id=13767373
 * https://news.ycombinator.com/item?id=13766933

(hacker threads, but from people claiming to be lawyers)

Best wishes

Mark


___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Github an licensing

[Mark Walters]

Dear All

On irc rlb pointed me to
https://joeyh.name/blog/entry/removing_everything_from_github/

IANAL so I don't know whether it is a real problem, a hypothetical
problem or not a problem.

My guess is that it can't affect the main notmuch license as the bulk of
notmuch's copyright is owned by people not responsible for the github
mirror (*), but it might mean that those of us responsible for the mirror are
illegally posting notmuch's code.

Does anyone have any views on this, and whether we should carry on
maintaining the github mirror?

Best wishes

Mark

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: github mirror

[Wael M. Nasreddine]

On Sat, Nov 21, 2015 at 8:23 AM, Wael M. Nasreddine
<wael.nasredd...@gmail.com> wrote:
>
> On Nov 21, 2015 5:48 AM, "Tomi Ollila" <tomi.oll...@iki.fi> wrote:
>>
>>
>> Exceptionally top-posting as the rest is left just for reference
>> (for anyone interested and loosing the thread context)
>>
>> Marking this as notmuch::fixed as
>>
>> https://github.com/notmuch/notmuch
>>
>> fixes this and is usually up-to-date (I use this link on one of my
>> notmuch installations)
>>
>> Interestingly the wiki is also in github (just that it is updated
>> March 28 -- based on https://github.com/notmuch )
>
> Hi Tomi,
>
> My syncer for the wiki might have died, I'll check on it today! If anyone
> notice it falling out of sync please fell free to give me a shout.
>

It turns out that I forgot to set it up on my new server, it is now
setup and running.

>
>>
>>
>> Tomi
>>
>>
>> On Sun, Apr 27 2014, Sam Halliday <sam.halli...@gmail.com> wrote:
>>
>> > Dear NotMuch,
>> >
>> > I have just started using notmuch and I really love it! I've been using
>> > web interfaces and proprietary mail clients for almost a decade and mutt
>> > before that (because I never got on well with rmail or gnus). Now, I'm
>> > trying to get all my life-hacker aficionados to follow suit.
>> >
>> > I was wanting to submit an RFE for you and to browse your source code to
>> > see how hard it would be to implement, but I was disappointed that it is
>> > all hosted on your own git repository with no issue tracker.
>> >
>> > While I appreciate that you probably use notmuch as your work flow
>> > manager, it is also quite common to use a social website such as github
>> > or getsatisfaction to interface with users. In my experience, github
>> > dramatically increases the number of contributions from users, in the
>> > form of what github calls "pull requests" (if you're a git user but not
>> > a github user, the term is confusing).
>> >
>> > Would it be possible to have a github project for notmuch? I'm certain
>> > the git repositories could be synchronised easily.
>> >
>> > A bridge between github's issue tracker and notmuch would be entirely
>> > possible: they have an API that would allow addition and removal of
>> > tags, as well as editing tickets. Actually, I would probably use such a
>> > thing :-)
>> >
>> > But in any case, my RFE/question was this: how hard would it be to have
>> > an optional mode of behaviour where tags are stored in the message
>> > itself, so that syncing with an IMAP server (e.g. via offlineimap)
>> > would make the tags available on all devices. This would negate the need
>> > for workarounds, such as shared notmuch databases, when users have
>> > multiple machines.
>> >
>> > It would also allow applications like offlineimap to introduce a gmail
>> > plugin that would copy the message into a folder according to its tags,
>> > so gmail labels and notmuch tags would be in sync.
>> >
>> > Best regards,
>> > Sam
>> >
>> > ___
>> > notmuch mailing list
>> > notmuch@notmuchmail.org
>> > http://notmuchmail.org/mailman/listinfo/notmuch
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch



-- 
Wael Nasreddine | Senior Full Stack Engineer at Dailymotion | (650) 933-3448
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: github mirror

[Wael M. Nasreddine]

On Nov 21, 2015 5:48 AM, "Tomi Ollila" <tomi.oll...@iki.fi> wrote:
>
>
> Exceptionally top-posting as the rest is left just for reference
> (for anyone interested and loosing the thread context)
>
> Marking this as notmuch::fixed as
>
> https://github.com/notmuch/notmuch
>
> fixes this and is usually up-to-date (I use this link on one of my
> notmuch installations)
>
> Interestingly the wiki is also in github (just that it is updated
> March 28 -- based on https://github.com/notmuch )

Hi Tomi,

My syncer for the wiki might have died, I'll check on it today! If anyone
notice it falling out of sync please fell free to give me a shout.
>
>
> Tomi
>
>
> On Sun, Apr 27 2014, Sam Halliday <sam.halli...@gmail.com> wrote:
>
> > Dear NotMuch,
> >
> > I have just started using notmuch and I really love it! I've been using
> > web interfaces and proprietary mail clients for almost a decade and mutt
> > before that (because I never got on well with rmail or gnus). Now, I'm
> > trying to get all my life-hacker aficionados to follow suit.
> >
> > I was wanting to submit an RFE for you and to browse your source code to
> > see how hard it would be to implement, but I was disappointed that it is
> > all hosted on your own git repository with no issue tracker.
> >
> > While I appreciate that you probably use notmuch as your work flow
> > manager, it is also quite common to use a social website such as github
> > or getsatisfaction to interface with users. In my experience, github
> > dramatically increases the number of contributions from users, in the
> > form of what github calls "pull requests" (if you're a git user but not
> > a github user, the term is confusing).
> >
> > Would it be possible to have a github project for notmuch? I'm certain
> > the git repositories could be synchronised easily.
> >
> > A bridge between github's issue tracker and notmuch would be entirely
> > possible: they have an API that would allow addition and removal of
> > tags, as well as editing tickets. Actually, I would probably use such a
> > thing :-)
> >
> > But in any case, my RFE/question was this: how hard would it be to have
> > an optional mode of behaviour where tags are stored in the message
> > itself, so that syncing with an IMAP server (e.g. via offlineimap)
> > would make the tags available on all devices. This would negate the need
> > for workarounds, such as shared notmuch databases, when users have
> > multiple machines.
> >
> > It would also allow applications like offlineimap to introduce a gmail
> > plugin that would copy the message into a folder according to its tags,
> > so gmail labels and notmuch tags would be in sync.
> >
> > Best regards,
> > Sam
> >
> > ___
> > notmuch mailing list
> > notmuch@notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: github mirror

[Tomi Ollila]

Exceptionally top-posting as the rest is left just for reference
(for anyone interested and loosing the thread context)

Marking this as notmuch::fixed as

https://github.com/notmuch/notmuch

fixes this and is usually up-to-date (I use this link on one of my
notmuch installations)

Interestingly the wiki is also in github (just that it is updated
March 28 -- based on https://github.com/notmuch )


Tomi


On Sun, Apr 27 2014, Sam Halliday <sam.halli...@gmail.com> wrote:

> Dear NotMuch,
>
> I have just started using notmuch and I really love it! I've been using
> web interfaces and proprietary mail clients for almost a decade and mutt
> before that (because I never got on well with rmail or gnus). Now, I'm
> trying to get all my life-hacker aficionados to follow suit.
>
> I was wanting to submit an RFE for you and to browse your source code to
> see how hard it would be to implement, but I was disappointed that it is
> all hosted on your own git repository with no issue tracker.
>
> While I appreciate that you probably use notmuch as your work flow
> manager, it is also quite common to use a social website such as github
> or getsatisfaction to interface with users. In my experience, github
> dramatically increases the number of contributions from users, in the
> form of what github calls "pull requests" (if you're a git user but not
> a github user, the term is confusing).
>
> Would it be possible to have a github project for notmuch? I'm certain
> the git repositories could be synchronised easily.
>
> A bridge between github's issue tracker and notmuch would be entirely
> possible: they have an API that would allow addition and removal of
> tags, as well as editing tickets. Actually, I would probably use such a
> thing :-)
>
> But in any case, my RFE/question was this: how hard would it be to have
> an optional mode of behaviour where tags are stored in the message
> itself, so that syncing with an IMAP server (e.g. via offlineimap)
> would make the tags available on all devices. This would negate the need
> for workarounds, such as shared notmuch databases, when users have
> multiple machines.
>
> It would also allow applications like offlineimap to introduce a gmail
> plugin that would copy the message into a folder according to its tags,
> so gmail labels and notmuch tags would be in sync.
>
> Best regards,
> Sam
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] doc: add README.md especially for github

[Tomi Ollila]

On Fri, Oct 24 2014, David Bremner  wrote:

> Apparently README.md overrides README, so this will show up instead of
> our generic README on github.
>
> If the user is already on github, then clicking a link for more
> information is not a hardship.

LGTM. although I'd prefer README.rst

Tomi

> ---
>  README.md | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 README.md
>
> diff --git a/README.md b/README.md
> new file mode 100644
> index 000..ce579d8
> --- /dev/null
> +++ b/README.md
> @@ -0,0 +1,15 @@
> +If you're reading this on github.com, this is a read-only mirror of
> +the notmuch project.
> +
> +For more information about the project, see
> +
> +  http://notmuchmail.org
> +
> +Please don't send us pull requests on github. If you have a feature
> +branch that you want us to look at, use `git send-email` to send to
> +notmuch at notmuchmail.org.
> +
> +For more information about contributing to the project, see
> +
> +
> +  http://notmuchmail.org/contributing/
> -- 
> 2.1.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] doc: add README.md especially for github

[David Bremner]

Tomi Ollila  writes:

> On Fri, Oct 24 2014, David Bremner  wrote:
>
>> Apparently README.md overrides README, so this will show up instead of
>> our generic README on github.
>>
>> If the user is already on github, then clicking a link for more
>> information is not a hardship.
>
> LGTM. although I'd prefer README.rst
>

OK, rst version pushed and shows up on github.

d

[PATCH] doc: add README.md especially for github

[David Bremner]

Apparently README.md overrides README, so this will show up instead of
our generic README on github.

If the user is already on github, then clicking a link for more
information is not a hardship.
---
 README.md | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 README.md

diff --git a/README.md b/README.md
new file mode 100644
index 000..ce579d8
--- /dev/null
+++ b/README.md
@@ -0,0 +1,15 @@
+If you're reading this on github.com, this is a read-only mirror of
+the notmuch project.
+
+For more information about the project, see
+
+  http://notmuchmail.org
+
+Please don't send us pull requests on github. If you have a feature
+branch that you want us to look at, use `git send-email` to send to
+notmuch at notmuchmail.org.
+
+For more information about contributing to the project, see
+
+
+  http://notmuchmail.org/contributing/
-- 
2.1.1

[PATCH] doc: add README.md especially for github

[David Bremner]

Apparently README.md overrides README, so this will show up instead of
our generic README on github.

If the user is already on github, then clicking a link for more
information is not a hardship.
---
 README.md | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 README.md

diff --git a/README.md b/README.md
new file mode 100644
index 000..ce579d8
--- /dev/null
+++ b/README.md
@@ -0,0 +1,15 @@
+If you're reading this on github.com, this is a read-only mirror of
+the notmuch project.
+
+For more information about the project, see
+
+  http://notmuchmail.org
+
+Please don't send us pull requests on github. If you have a feature
+branch that you want us to look at, use `git send-email` to send to
+notmuch@notmuchmail.org.
+
+For more information about contributing to the project, see
+
+
+  http://notmuchmail.org/contributing/
-- 
2.1.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] doc: add README.md especially for github

[Tomi Ollila]

On Fri, Oct 24 2014, David Bremner da...@tethera.net wrote:

 Apparently README.md overrides README, so this will show up instead of
 our generic README on github.

 If the user is already on github, then clicking a link for more
 information is not a hardship.

LGTM. although I'd prefer README.rst

Tomi

 ---
  README.md | 15 +++
  1 file changed, 15 insertions(+)
  create mode 100644 README.md

 diff --git a/README.md b/README.md
 new file mode 100644
 index 000..ce579d8
 --- /dev/null
 +++ b/README.md
 @@ -0,0 +1,15 @@
 +If you're reading this on github.com, this is a read-only mirror of
 +the notmuch project.
 +
 +For more information about the project, see
 +
 +  http://notmuchmail.org
 +
 +Please don't send us pull requests on github. If you have a feature
 +branch that you want us to look at, use `git send-email` to send to
 +notmuch@notmuchmail.org.
 +
 +For more information about contributing to the project, see
 +
 +
 +  http://notmuchmail.org/contributing/
 -- 
 2.1.1

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] doc: add README.md especially for github

[David Bremner]

Tomi Ollila tomi.oll...@iki.fi writes:

 On Fri, Oct 24 2014, David Bremner da...@tethera.net wrote:

 Apparently README.md overrides README, so this will show up instead of
 our generic README on github.

 If the user is already on github, then clicking a link for more
 information is not a hardship.

 LGTM. although I'd prefer README.rst


OK, rst version pushed and shows up on github.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

github

[Felipe Contreras]

Jameson Graef Rollins wrote:
> On Mon, May 12 2014, Felipe Contreras  wrote:
> > How would our development cycle be controlled by GitHub?
> >
> > The whole point of a distributed VCS is that there isn't a single
> > central repository you rely on.
> 
> If this is true then why are we even talking about github?

I don't recall the details of the original mail, but I don't see why we
can't have a github.com/notmuch/notmuch repository *in addition* to
whatever other repository we choose as the main one.

-- 
Felipe Contreras

github

[Wael Nasreddine]

Jameson Graef Rollins  writes:

> On Mon, May 12 2014, Felipe Contreras  wrote:
>> How would our development cycle be controlled by GitHub?
>>
>> The whole point of a distributed VCS is that there isn't a single
>> central repository you rely on.
>
> If this is true then why are we even talking about github?
>
We're talking about providing a mirror on Github. Among many things
Github is an amazing code browser that I (among many people) are used to
use. Anyway this discussion is solved by providing a mirror[0] which is
updated every minute to reflect official notmuch status in realtime.

[0]: https://github.com/notmuch/notmuch

> jamie.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
-- next part --
--
Wael Nasreddine | SRE at Google | wael.nasreddine at gmail.com | (650) 735-1773
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140516/35255fe7/attachment.pgp>

github

[Jameson Graef Rollins]

On Mon, May 12 2014, Felipe Contreras  wrote:
> How would our development cycle be controlled by GitHub?
>
> The whole point of a distributed VCS is that there isn't a single
> central repository you rely on.

If this is true then why are we even talking about github?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140516/4bf52f64/attachment.pgp>

Re: github

[Jameson Graef Rollins]

On Mon, May 12 2014, Felipe Contreras felipe.contre...@gmail.com wrote:
 How would our development cycle be controlled by GitHub?

 The whole point of a distributed VCS is that there isn't a single
 central repository you rely on.

If this is true then why are we even talking about github?

jamie.


pgpH219XD6zhJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: github

[Wael Nasreddine]

Jameson Graef Rollins jroll...@finestructure.net writes:

 On Mon, May 12 2014, Felipe Contreras felipe.contre...@gmail.com wrote:
 How would our development cycle be controlled by GitHub?

 The whole point of a distributed VCS is that there isn't a single
 central repository you rely on.

 If this is true then why are we even talking about github?

We're talking about providing a mirror on Github. Among many things
Github is an amazing code browser that I (among many people) are used to
use. Anyway this discussion is solved by providing a mirror[0] which is
updated every minute to reflect official notmuch status in realtime.

[0]: https://github.com/notmuch/notmuch

 jamie.
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
--
Wael Nasreddine | SRE at Google | wael.nasredd...@gmail.com | (650) 735-1773


pgpKbarkhGqUj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: github

[Felipe Contreras]

Jameson Graef Rollins wrote:
 On Mon, May 12 2014, Felipe Contreras felipe.contre...@gmail.com wrote:
  How would our development cycle be controlled by GitHub?
 
  The whole point of a distributed VCS is that there isn't a single
  central repository you rely on.
 
 If this is true then why are we even talking about github?

I don't recall the details of the original mail, but I don't see why we
can't have a github.com/notmuch/notmuch repository *in addition* to
whatever other repository we choose as the main one.

-- 
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

github

[Felipe Contreras]

On Mon, May 12, 2014 at 9:30 PM, Jameson Graef Rollins
 wrote:
> On Sun, Apr 27 2014, Jani Nikula  wrote:
>> To be honest, I am slightly concerned by the popularity of
>> github. Despite being a hosting site primarily for open source, it *is*
>> a proprietary platform. Source code hosting is plain git, but AFAIK all
>> the rest (review process, issue tracking, and so on) is pretty much at
>> the whim and mercy of the company running it. They make a change, you
>> adapt. If you don't want to adapt, it's not easy to switch over to
>> another service provider either if you've built your process around
>> github.
>>
>> So even if the features of github amazed me (they don't), I would have
>> pretty strong reservations about relying on them.
>
> There seems to have been a lot of discussion on the list recently about
> github.  I just want to express my very strong agreement with Jani's
> sentiment above.  A lot of us in the notmuch community moved to notmuch
> because we didn't want our email controlled by a single service provider
> (e.g. gmail).  I don't want our development cycle controlled by github
> (or any other proprietary SCM) for many of the same reasons.

How would our development cycle be controlled by GitHub?

The whole point of a distributed VCS is that there isn't a single
central repository you rely on.

-- 
Felipe Contreras

github

[Jameson Graef Rollins]

On Sun, Apr 27 2014, Jani Nikula  wrote:
> To be honest, I am slightly concerned by the popularity of
> github. Despite being a hosting site primarily for open source, it *is*
> a proprietary platform. Source code hosting is plain git, but AFAIK all
> the rest (review process, issue tracking, and so on) is pretty much at
> the whim and mercy of the company running it. They make a change, you
> adapt. If you don't want to adapt, it's not easy to switch over to
> another service provider either if you've built your process around
> github.
>
> So even if the features of github amazed me (they don't), I would have
> pretty strong reservations about relying on them.

There seems to have been a lot of discussion on the list recently about
github.  I just want to express my very strong agreement with Jani's
sentiment above.  A lot of us in the notmuch community moved to notmuch
because we didn't want our email controlled by a single service provider
(e.g. gmail).  I don't want our development cycle controlled by github
(or any other proprietary SCM) for many of the same reasons.

The current notmuch development process, that's been built up over the
last five years, is the most efficient and effective I've ever worked
with.  It's really a well-oiled machine.  Newcomers (always welcome!)
should give it a try before suggesting we abandon it.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140512/8a6495ad/attachment.pgp>

Re: github

[Jameson Graef Rollins]

On Sun, Apr 27 2014, Jani Nikula j...@nikula.org wrote:
 To be honest, I am slightly concerned by the popularity of
 github. Despite being a hosting site primarily for open source, it *is*
 a proprietary platform. Source code hosting is plain git, but AFAIK all
 the rest (review process, issue tracking, and so on) is pretty much at
 the whim and mercy of the company running it. They make a change, you
 adapt. If you don't want to adapt, it's not easy to switch over to
 another service provider either if you've built your process around
 github.

 So even if the features of github amazed me (they don't), I would have
 pretty strong reservations about relying on them.

There seems to have been a lot of discussion on the list recently about
github.  I just want to express my very strong agreement with Jani's
sentiment above.  A lot of us in the notmuch community moved to notmuch
because we didn't want our email controlled by a single service provider
(e.g. gmail).  I don't want our development cycle controlled by github
(or any other proprietary SCM) for many of the same reasons.

The current notmuch development process, that's been built up over the
last five years, is the most efficient and effective I've ever worked
with.  It's really a well-oiled machine.  Newcomers (always welcome!)
should give it a try before suggesting we abandon it.

jamie.


pgpcj9A5WINCH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: github

[Felipe Contreras]

On Mon, May 12, 2014 at 9:30 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 On Sun, Apr 27 2014, Jani Nikula j...@nikula.org wrote:
 To be honest, I am slightly concerned by the popularity of
 github. Despite being a hosting site primarily for open source, it *is*
 a proprietary platform. Source code hosting is plain git, but AFAIK all
 the rest (review process, issue tracking, and so on) is pretty much at
 the whim and mercy of the company running it. They make a change, you
 adapt. If you don't want to adapt, it's not easy to switch over to
 another service provider either if you've built your process around
 github.

 So even if the features of github amazed me (they don't), I would have
 pretty strong reservations about relying on them.

 There seems to have been a lot of discussion on the list recently about
 github.  I just want to express my very strong agreement with Jani's
 sentiment above.  A lot of us in the notmuch community moved to notmuch
 because we didn't want our email controlled by a single service provider
 (e.g. gmail).  I don't want our development cycle controlled by github
 (or any other proprietary SCM) for many of the same reasons.

How would our development cycle be controlled by GitHub?

The whole point of a distributed VCS is that there isn't a single
central repository you rely on.

-- 
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Github?

[Tomi Ollila]

On Sat, May 10 2014, "Wael M. Nasreddine"  wrote:

> On Fri, May 9, 2014 at 6:21 PM, David Bremner  wrote:
>> Felipe Contreras  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 at 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

Github?

[David Bremner]

Felipe Contreras  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

Github?

[Felipe Contreras]

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

It's YAML. So, yes.

-- 
Felipe Contreras

Re: Github?

[Tomi Ollila]

On Sat, May 10 2014, Wael M. Nasreddine wael.nasredd...@gmail.com wrote:

 On Fri, May 9, 2014 at 6:21 PM, David Bremner da...@tethera.net wrote:
 Felipe Contreras felipe.contre...@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.nasredd...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[Felipe Contreras]

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

It's YAML. So, yes.

-- 
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Github?

[Wael M. Nasreddine]

On Fri, May 9, 2014 at 6:21 PM, David Bremner  wrote:
> Felipe Contreras  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 at gmail.com | (650) 
735-1773

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 >= 
> > 
> > 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.

Github?

[Amadeusz Żołnowski]

Hi,

Wael Nasreddine  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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140509/3157ffb4/attachment.pgp>

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 >= 

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.

Github?

[David Bremner]

David Bremner  writes:

> Wael Nasreddine  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


-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 647 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140509/7d713f07/attachment.pgp>

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 >= 
> > > 
> > > 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

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 >= 
> 
> 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

Github?

[David Bremner]

Wael Nasreddine  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

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

Github?

[Wael Nasreddine]

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 at gmail.com> wrote:

> W. Trevor King wrote:
> > On Thu, May 08, 2014 at 11:18:23PM +, 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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140509/a6838aa3/attachment.html>

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.

Github?

[Wael Nasreddine]

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

> On Thu, May 08, 2014 at 11:18:23PM +, 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
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140509/89808ba7/attachment.html>

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 at 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

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
> > > 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.

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

Github?

[Wael Nasreddine]

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

> Wael Nasreddine  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
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/1089ac22/attachment.html>

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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[Amadeusz Żołnowski]

Hi,

Wael Nasreddine wael.nasredd...@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


pgpoOdZZjxYdQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[David Bremner]

Felipe Contreras felipe.contre...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[Wael M. Nasreddine]

On Fri, May 9, 2014 at 6:21 PM, David Bremner da...@tethera.net wrote:
 Felipe Contreras felipe.contre...@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.nasredd...@gmail.com | (650) 735-1773
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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
> 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.

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

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

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

Github?

[Felipe Contreras]

W. Trevor King wrote:
> On Thu, May 08, 2014 at 11:18:23PM +, 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

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

Github?

[W. Trevor King]

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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/ec773ffa/attachment.pgp>

Github?

[Wael Nasreddine]

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 at 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  wrote:
> > > On Thu, 08 May 2014, Wael Nasreddine 
> wrote:
> [...]
> > >> Any thoughts on moving to Github?
> > > http://mid.gmane.org/87wqea7c37.fsf at 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 at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/485c2d47/attachment.html>

Github?

[W. Trevor King]

On Fri, May 09, 2014 at 12:13:51AM +, 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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/ecf5baf4/attachment.pgp>

Github?

[W. Trevor King]

On Thu, May 08, 2014 at 11:18:23PM +, 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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/d9734944/attachment-0001.pgp>

Submodules for language bindings (was: Github?)

[W. Trevor King]

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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

Submodules for language bindings (was: Github?)

[W. Trevor King]

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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

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

Github?

[W. Trevor King]

On Thu, May 08, 2014 at 07:54:38PM +, 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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/2e1e6368/attachment.pgp>

Github?

[Wael M. Nasreddine]

On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
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 at 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 
>> wrote:
>> > > On Thu, 08 May 2014, Wael Nasreddine 
>> wrote:
>> [...]
>> > >> Any thoughts on moving to Github?
>> > > http://mid.gmane.org/87wqea7c37.fsf at 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 at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>>
>


-- 
Wael Nasreddine | Software Engineer |  wael.nasreddine at gmail.com |  (650)
735-1773
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/c1421553/attachment.html>

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  wrote:
> > On Thu, 08 May 2014, Wael Nasreddine  wrote:
[...]
> >> Any thoughts on moving to Github?
> > http://mid.gmane.org/87wqea7c37.fsf at 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

Github?

[Eric]

On Thu, 08 May 2014 09:13:56 +0200, Jani Nikula  wrote:
> On Thu, 08 May 2014, Wael Nasreddine  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 at 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

Github?

[Jani Nikula]

On Thu, 08 May 2014, Wael Nasreddine  wrote:
> I forgot to mention that I also enabled Travis-CI for notmuch, you can
> access it here , 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

Github?

[Wael Nasreddine]

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 at 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
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/c2f868ab/attachment.html>

Github?

[Wael Nasreddine]

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
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/14a8cf54/attachment.html>

Re: Github?

[Jani Nikula]

On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@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@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[Jani Nikula]

On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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 j...@nikula.org wrote:
  On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@gmail.com wrote:
[...]
  Any thoughts on moving to Github?
  http://mid.gmane.org/87wqea7c37@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

Re: Github?

[Wael Nasreddine]

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+notm...@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 j...@nikula.org wrote:
   On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@gmail.com
 wrote:
 [...]
   Any thoughts on moving to Github?
   http://mid.gmane.org/87wqea7c37@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

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[Wael M. Nasreddine]

On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
wael.nasredd...@gmail.comwrote:

 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+notm...@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 j...@nikula.org
 wrote:
   On Thu, 08 May 2014, Wael Nasreddine wael.nasredd...@gmail.com
 wrote:
 [...]
   Any thoughts on moving to Github?
   http://mid.gmane.org/87wqea7c37@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.nasredd...@gmail.com |  (650)
735-1773
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[W. Trevor King]

On Thu, May 08, 2014 at 07:54:38PM +, 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


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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.nasredd...@gmail.comwrote:
 
  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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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.nasredd...@gmail.comwrote:
[...]
  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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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.nasredd...@gmail.comwrote:
 [...]
   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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Submodules for language bindings (was: Github?)

[W. Trevor King]

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


signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Github?

[David Bremner]

Wael Nasreddine wael.nasredd...@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

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch