[Sam Halliday] Re: github mirror

[Sam Halliday] Re: github mirror

[Sam Halliday]

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

Sorry, I replied to jani and not the list...


[-- Attachment #2: Type: message/rfc822, Size: 4742 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 3598 bytes --]

Jani Nikula <jani@nikula.org> writes:
> We also maintain fairly high standards for the contributions we
> accept, so the review has a significant role in the process.

In my experience the github pull review process is by far superior to
any other solution. If you've never done a github review, I would
strongly recommend doing one just for fun to see what you think of
it. You can basically add line comments in the code and have a
discussion on the finer points of commits. And then, to address those
comments, it's as simple as the contributor pushing to their repo again
and the review is updated. Repeat until the "merge" button is pressed
(or the equivalent git commands, of course).

But you are correct, it would be a big change from your current
setup.

>> Would it be possible to have a github project for notmuch? I'm certain
>> the git repositories could be synchronised easily.
>
> This part is trivial, but on its own it doesn't provide any obvious
> benefits.

The benefit would be - perhaps - an increase in the number of patches
for you to review :-). Plus, free hosting, and easier to track down who
aims to contribute to the project. It would also expose you to a larger
audience. I find a lot of cool projects just by jumping around
interesting developers on github.

I can only cite my own experience, but I have received a lot more
contributions (out of the blue) since moving to github than I did when I
was running repositories on savannah, sourceforge or google code. It's
just so much easier to click the "fork" button, then make some commits,
and click the "pull request" button. If I were contributing to you, it
requires having to learn your process, create diffs and then attach
them, and then after a review it means tracking down the bits of the
code you're referring to and manually reconciling that with my repo and
sending you more diffs. Using github, it's like all open source
developers agree on a basic set of common processes.


>> 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 :-)
>
> I'm sure all of this would be entirely possible; I'm not so sure it
> would be worth the effort. But hey, if someone is willing to do the
> work, patches are welcome. By email. ;)

Heh, well I might just end up doing something like that because the more
I use notmuch, the more I think it could be used for other parts of my
workflow. For example, I wrote https://github.com/fommil/zibaldone a
couple of years ago for a friend but I never quite got it to a stage
where I would use it myself. If I could use notmuch to manage a large
collection of notes, that would be interesting, and would mean I could
drop to the zibaldone visual (auto-cluster) mode and use a touchscreen
to move the ideas around and find new connections. I'm using Lucene in
that project, but I could rewrite the backend to use notmuch (or xapian
directly). There are a few tickets on that project I'd love to implement
(on the machine learning side) but on their own are not convincing
enough for me to start using it.

That said, Zibaldone and note organisation is low priority. If I were to
do anything with notmuch it would be improving syncing with gmail (so a
tag in notmuch equates to a label in their interface) or at the very
least sharing the same tag structure across multiple notmuch
machines. Being able to see the same thing on multiple machines using
one canonical data source is really important for me.


[-- Attachment #2.1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3.2: Type: application/pgp-signature, Size: 197 bytes --]

[Sam Halliday] Re: github mirror

[Sam Halliday]

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

and another one


[-- Attachment #2: Type: message/rfc822, Size: 1847 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 670 bytes --]

Sam Halliday <sam.halliday@gmail.com> writes:
> If I were to do anything with notmuch it would be improving syncing
> with gmail (so a tag in notmuch equates to a label in their interface)
> or at the very least sharing the same tag structure across multiple
> notmuch machines. Being able to see the same thing on multiple
> machines using one canonical data source is really important for me.

FYI on gmail integration. @aroig has created a bunch of patches that
use a mail header for syncing the gmail labels with offlineimap. This is
a potential route to implementing persistent notmuch tagging on the
server side: https://github.com/OfflineIMAP/offlineimap/pull/43

[-- Attachment #2.1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3.2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [Sam Halliday] Re: github mirror

[Jani Nikula]

On Sun, 27 Apr 2014, Sam Halliday <sam.halliday@gmail.com> wrote:
> Sorry, I replied to jani and not the list...

...and I in turn replied to the private message. Oops. Let's try again.

On Sun, 27 Apr 2014, Sam Halliday <sam.halliday@gmail.com> wrote:
> In my experience the github pull review process is by far superior to
> any other solution.

I read and write code in Emacs. I read and write email in Emacs. I read
and write basically anything I can in Emacs. I have near total control
of that environment, mainly limited by my abilities.

Any review process that forces me to review code (in other words, read
code and write text) in an environment that I don't have control over
will be inferior to me.

The same is true for people using some other editor or mail client; they
can choose and control that environment, but they have no control over
github.

> If I were contributing to you, it requires having to learn your
> process, create diffs and then attach them, and then after a review it
> means tracking down the bits of the code you're referring to and
> manually reconciling that with my repo and sending you more
> diffs. Using github, it's like all open source developers agree on a
> basic set of common processes.

Funny you should say that; it used to be that emailed patches and
mailing list based review were the common process! I am not sure which
one is more popular these days (or what would be the appropriate metric
for comparing).

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.

Disclaimer, I don't make the calls for this project, I only speak for
myself.

BR,
Jani.