RFC: Creating a new org-contrib.git repository

RFC: Creating a new org-contrib.git repository

[Bastien]

Hi all,

the idea has been surfacing here and there on the list, time to get
your feedback on the idea and your help on its technical aspects.

I plan to extract org-contrib.git from org-mode.git.

The org-*tar.gz/zip packages would distribute the contrib/ directory
as they do now, so there would be no change for users installing from
these archives.

For users would use Org from git, they would just need to update a
git submodule, then all files would be in contrib/ as they are now.

So on the overall, this change would only affect developers: those
who contribute to Org's core would push commits to org-mode.git and
those who contribute to contrib/ would push commits to org-contrib.git.

The advantage is (1) to separate Org's core logs (the one that are
further merged into Emacs) from the org-contrib.git logs, and (2) to
open org-contrib.git more widely, i.e., make it safe for anyone to
push commits there with no fear of doing something wrong in Org's
main repository.  Also, remember that org-contrib.git would be open
for contributors without signing FSF papers first.

Does anyone think this is a very bad idea?  Why?

On the technical side: does anyone know what incantations needs to
be done for this?  I use git filter-branch (and its --tree-filter
option) from time to time but I'm definitely not an expert.  What
we want at the end is:

org-mode.git: 
  with no contrib/ directory
  with no commits affecting the contrib/ directory only.
  with the maint and master branches

org-contrib.git/
  with all files from contrib/
  with all commits affecting the contrib/ directory.
  with just a master branch

Does anyone feel confident enough about this to provide a recipe?

This will be the last "structural" move before releasing 8.0.

Thanks in advance for your help!

-- 
 Bastien

Re: RFC: Creating a new org-contrib.git repository

[Achim Gratz]

Bastien writes:
> The advantage is (1) to separate Org's core logs (the one that are
> further merged into Emacs) from the org-contrib.git logs, and (2) to
> open org-contrib.git more widely, i.e., make it safe for anyone to
> push commits there with no fear of doing something wrong in Org's
> main repository.  Also, remember that org-contrib.git would be open
> for contributors without signing FSF papers first.

I would like to remark that if these files should then move into core
there will be lots of tedious work to ensure that all contributions are
assigned to the FSF by that time.  In that sense, org-contrib could
become a dead-end rather than a staging area.

If you only want wider push access to contrib/, then that could probably
be done by a pre-commit hook.

Or we could make it easier to pull from contributors' repositories by
having the build system deal with submodules and requesting that
contributions provide the necessary hooking in terms of a Makefile.
That'd mean that those contributors who can't or don't want to assign
copyright to the FSF keep their contributions in their own repositories.

> On the technical side: does anyone know what incantations needs to
> be done for this?  I use git filter-branch (and its --tree-filter
> option) from time to time but I'm definitely not an expert.  What
> we want at the end is:

Rewriting the history so that it stays meaningful will not be easy and
it will lose (or alter) information whenever a file moved between
contrib and core in the past.  This is not just a few incantations, you
would have to write specific scripting to do this.

I'd rather try to get as much contrib/ as possible into core and then
re-assess what's left.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: RFC: Creating a new org-contrib.git repository

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

>> On the technical side: does anyone know what incantations needs to
>> be done for this?  I use git filter-branch (and its --tree-filter
>> option) from time to time but I'm definitely not an expert.  What
>> we want at the end is:
>
> Rewriting the history so that it stays meaningful will not be easy and
> it will lose (or alter) information whenever a file moved between
> contrib and core in the past.  This is not just a few incantations, you
> would have to write specific scripting to do this.

Yes -- my experiments show me this so far, it is not easy.

So really question the usefulness of the whole move in fact.

> I'd rather try to get as much contrib/ as possible into core and then
> re-assess what's left.

I see your point, but this cannot be done without asking the Emacs
developers what they consider being really useful for Emacs.  Again,
not something that I will have time to do before 8.0.

Let's continue to see if this is desirable and possible without
too much dirty work, and maybe postpone this after 8.0.

-- 
 Bastien