Re: What a modern collaboration toolkit looks like

[Tassilo Horn <tassilo@member.fsf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> The current way with posting patches on emacs-devel, getting review,
>> rewriting the patches, yet more review and eventually being included
>> (but still with no write access) can make the work much harder.
>> [...]
>> I could say, hey, I've developed this new foo-mode, please look at my
>> git repository at http://www.tsdh.de/repos/git/foo, get the review,
>> change it till everybody is satisfied and eventually one of the core
>> devs could pull the changes.
>
> Please explain how the former is harder than the latter.

At least it's harder for the contributor.  Let's say my new feature is
quite complex and needs some time to get it right.  With CVS I have to
do it in one big step.  Till it's not finished and ready for inclusion I
simply cannot commit.

With git I can commit locally whenever I want.  If I have three
alternative approaches to handle something I can easily create three
local branches and switch between them to test which is better.  And if
I do somthing stupid (which I always do!) I can easily revert to a
previous version.

To do something like local branches with CVS I would need to checkout
the complete repository several times and still I could not commit to
revert after a wrong decision.  So currently I make file backups once in
a while which is really a pain.

> You still need to wait for review and approval.

Sure, but as I said, I consider that a good thing.  And if the reviewers
at the 13th review say that my last changes are completely stupid, I can
easily revert to revision 12 if we'd use git or another distributed VCS.

> OTOH, having a patch pushed into my INBOX and staring in my face runs
> better chances that I will review it than if I need to be on-line and
> type some commands first just to see it.

Ok, so I'd write a mail with my repository location and a `git diff'
output.

>> There's a nice video at youtube where Linus Torvalds talks about git
>> where he discribes the benefits of distributed VCSs (in a very
>> entertaining way).
>
> Linus and others invented git because Linux kernel development is
> radically different from Emacs development.  To start using git, we
> need first get to the point the Linux kernel developers are at: lots
> of developers independently developing all kinds of extensions.

Git (and any other distributed VCS) can be used in a CVS style with one
main repository without loosing any of its benefits.

> _And_ we need a head maintainer who works on nothing else but
> integration of features she likes into the product that is eventually
> released.

I don't see the difference between pulling from somebody (after a
review) and applying the patches attached to a mail.

Of course the core devs would have write access to the main repository,
so all of them could push their own changes into it (plus changes they
reviewed from others).  So any core dev would be a potential integrator.

> Please also don't forget that, unlike a Linux kernel, Emacs must have
> good user-level documentation.  So decentralized development needs
> also solve the problem of producing high quality manuals.

I guess that's part of the review.  "Hey, nice work.  Please come back
when the docs are finished."

>> IMO this would change with a VCS like git, too.  On problem with the
>> current situation is that possible contributors might fear that their
>> changes break something or won't be liked by the core devs.  So they
>> don't even try it at all.
>
> I don't see why.  Someone who wants just to try things can do that in
> their sandbox; no one will ever know they did it unless they tell or
> post the patches.  How is this different from using git?

As I said above: You can develop in little steps and still use all the
benefits a VCS offers (committing, reverting, branching, merging,
tagging).

>> So to sum up: There are quite a few young devs that write good elisp
>> code
>
> Do you have numbers? or is "few" == 1 here?

I know at least two beside me: David O'Toole and Michael Olson.  And at
least the latter uses git for all his projects.  But I'm sure there are
many more.

Bye,
Tassilo