[Sam Halliday] Re: github mirror

* [Sam Halliday] Re: github mirror
@ 2014-04-27 18:53 Sam Halliday
  2014-04-27 20:26 ` Jani Nikula
  0 siblings, 1 reply; 7+ messages in thread
From: Sam Halliday @ 2014-04-27 18:53 UTC (permalink / raw)
  To: notmuch

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

^ permalink raw reply	[flat|nested] 7+ messages in thread