Re: Org-mode development (was: Vacation, and 5.04)

[Adam Spiers <orgmode@adamspiers.org>]

Carsten Dominik (dominik@science.uva.nl) wrote:
> On Jul 20, 2007, at 17:28, Adam Spiers wrote:
> >This might be a pertinent moment to bring up the topic of revision
> >control ... or actually it might be a particularly bad moment,
> >considering that the maintainer is about to vanish for 3 weeks!  But I
> >wanted to propose the idea of adopting a distributed revision control
> >system.  This would allow any individual coder to (amongst other
> >benefits) easily create short-term feature branches or bugfix branches
> >off Carsten's releases, share them publically with others for testing,
> >and enable very low-cost merging back into the mainstream.  To use the
> >current situation as one example, this would mean that Carsten can
> >relax happily on the beach (or wherever he is ;-) knowing that his
> >absence is guaranteed *not* to hold any progress back, even if he
> >decided to stay there for several months ;-)
> 
> Now we are talking..... :-)

... and then we stopped - sorry for the long delay, I spent two weeks
on a beach myself and it has taken me rather too long to address the
resulting backlog :-)

> >In case anyone's unfamiliar with the benefits of distributed revision
> >control (vs. centralized, e.g. CVS/svn), enjoy this great talk by
> >Linus Torvalds at google:
> >
> >  http://www.youtube.com/watch?v=4XpnKHJAok8
> >
> >It claims to be about git, but actually it's more about distributed
> >revision control systems in general - everything he says applies to
> >similar systems such as mercurial.
> 
> Thanks for this enjoyable link - lots of fun to watch Linus like this.

Here's an interesting follow-on - a reply from Linus to one of the KDE
maintainers who was still not convinced that a decentralized model is
always a benefit:

  http://lwn.net/Articles/246381/

> I'd like to make some comments about the development model or Org-mode
> and put it up here for discussion.
> 
> - Org-mode is part of Emacs - this means that I can only accept patches
>   from people who have signed the appropriate papers with the FSF.  You
>   might have noticed in the past that I usually don't simply apply a
>   patch.  I change it considerably or re-implement the feature, to make
>   sure that we will not run into copyright issues.  If you want to
>   contribute to org-mode and make life easy for me, write to
>   assign@gnu.org and ask for the paperwork to become a contributor to
>   org-mode in Emacs, and let me know what you have done so so that I
>   can start to use your patches directly.

I'd be happy to do this to save you work - though that is of course
making the big assumption that my patches are usable in their
unaltered form ;-)

> - The second reason why I often don't apply patches exactly as submitted
>   is because I see my role in filtering and shaping features so that
>   they fit exactly into the feel and look of Org-mode as I see it.
>   I don't want it to loose focus.

We are extremely lucky to have such a diligent and effective maintainer!

>   You might see this as a good thing, but you could also see this
>   as slowing down development.

If that's true, it *is* a good thing because otherwise I could hardly
keep up with the rapid pace :-)

> - I have never used git or a similar distributed tool - so I would
>   have to learn how to use them.

I can't speak for git, but one of the beautiful things about mercurial
is its simplicity; as a result, the learning curve is extremely
shallow:

  http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart

There are a load of excellent docs too, e.g. 

  http://www.selenic.com/mercurial/wiki/index.cgi
  http://hgbook.red-bean.com/hgbook.html

There's not much more to it for basic usage.  Pushing/pulling can be
done with remote repositories, e.g. via ssh or HTTP or even mail.
Releases can be symbolically tagged.  Merges are made painless.  A
built-in standalone web server lets anyone publish their repositories
instantly via 'hg serve', e.g. 

  http://www.adamspiers.org/hg/

A nice visual tool is bundled to help keep on top of even complicated
branching situations:

  http://lwn.net/Articles/140350/

I would argue that even when still sticking to a centralized
development model, it is still worth switching away from CVS or
similar:

  - Bidirectional syncing with CVS and other SCMs well supported
  - Atomic changesets
  - Robust repository format
     - including native cryptographic integrity checks
  - Renames done right
  - Symlink support
  - Branching and merging becomes painless
     - enables others even if you don't use it personally

I could go on but it's time to shut up now I think ;-)