New development organization

* New development organization - DRAFT, please comment
@ 2010-05-26 11:54 Carsten Dominik
  2010-05-27 13:13 ` Eric Schulte
  0 siblings, 1 reply; 8+ messages in thread
From: Carsten Dominik @ 2010-05-26 11:54 UTC (permalink / raw)
  To: emacs-org-mode-help gnu

                               New setup
                               =========

Author: Carsten Dominik
Date: 2010-05-26 13:53:28 CEST

Hi everyone,

I am very excited about the great response to my request for help by a
co-maintainer.  As a result of the different offers and ideas, we are
going to modify the development model for Org-mode.  Here is my
proposal on how things should work in the future.  Let me know if I
overlooks something.

Table of Contents
=================
1 The git repository stays at git://repo.or.cz/org-mode
2 Patches sent to the mailing list are automatically registered
3 Feature requests and bug reports will be tracked in a text file
4 A small number of people should commit to Org's master branch
5 Other contributors
     5.1 Submitting patches
     5.2 Taking charge of a reported bug or a feature request
     5.3 Copyright

1 The git repository stays at git://repo.or.cz/org-mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There was some discussion to move it to GitHub, but I think the
advantages are small.  Of cause you can run your own mirror on GitHub.
Or, even better fork it from John Wiegley's mirror at
[http://github.com/jwiegley/org-mode].  Patches you develop there can be
applied and feature branches merged when a piece of development is
accepted into Org-mode.

2 Patches sent to the mailing list are automatically registered
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

John runs a patchwork server at

[http://patchwork.newartisans.com/project/org-mode]

This server scans mailing list posts for included patches, either
plainly in the mail text, or as text attachments (mime-type text,
subtypes "x-patch", "x-diff", or "plain").  John will oversee the
discussion about these patches, and apply the ones that are accepted.
I am sure that I will be involved as well, for some patches.

3 Feature requests and bug reports will be tracked in a text file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This file lives on Worg, at

[http://orgmode.org/work/org-issues.org]

David Maus is the main maintainer of this file, he will collect issues
and tasks and organize them.  I envision that people with Worg access
can go in and assign an issue to themselves and update the information
while work is being done on the issue.  How exactly this should be
done I would like to leave to David.

4 A small number of people should commit to Org's master branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Currently I think only these people should commit to the master branch:

- John Wiegley, when he is applying patches

- Eric Schulte and Dan Davison, for all things concerning org-babel.
   These are the files currently in contrib/babel, they will move to
   lisp/babel at some point in the future.  Eric and Dan also make
   changes to some other Org files where necessary to make the
   interaction with babel smooth.

- Tom Breton for developing a test framework for Org, in the
   subdirectory "testing".

- Bastien for the occasional patch he handles, and everything
   necessary to keep worg and the website running

- Carsten for all kinds of changes, including adding new modules,
   design changes etc etc.

5 Other contributors
~~~~~~~~~~~~~~~~~~~~~

Many people have offered help with individual issues.  This help is
more than welcome.

5.1 Submitting patches
=======================

Everyone can submit patches to the mailing list.  See below about
copyright issues.  When people submit patches, everyone can help by
studying them, applying them locally and reporting back to the mailing
list, in the same thread.  This will make it easier for John to decide
if the patch should be applied.

Note that we are abandoning the standard Emacs ChangeLog file to
record changes.  In a modern version control system like git,
ChangeLog is duplicating information that should be in the commit
message, and it is the main cause of merge conflicts.  From now on,
patches should not contain changes to the ChangeLog file, but should
contains a similarly formatted entry in the commit message.  An
example is [here].  If you are using magit in Emacs, such entries are
easily made by pressing "C" in the diff listing.  Another option to
make the entries is to use `C-x 4 a' in the changed function.  This
will create entries in the ChangeLog file, and you can then cut and
paste these to the commit message and remove the indentation.

[here]: http://article.gmane.org/gmane.emacs.orgmode/25574

5.2 Taking charge of a reported bug or a feature request
=========================================================

You can take charge of a reported bug or a feature request by noting
so in the issue tracker file.  Also reply to the mail that contained
the report/request, indicating that you will take care of this issue.
In this way, we avoid unnecessary duplication.

5.3 Copyright
==============

Please note that only patches that change less than 10 lines can be
used without formal treatment of copyright.  By submitting such a
patch, you are putting this patch into the public domain and allow us
to include it into Emacs and distribute it under GPL version 3.

If you want to make larger contributions, please sign the papers with
the FSF.  I am keeping a list of people from who I have these papers
in [this file on Worg].  If you are not on this list but should be,
please contact me.

[this file on Worg]: http://orgmode.org/worg/org-contribute.php#contributors_with_fsf_papers

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