Re: Emacs contributions, C and Lisp

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
> So I really have no idea what is this gripe all about; we just do what
> every other project out there does.  I can see how it would be easier
> for contributors to just use fire-and-forget methods, but that's not
> how projects such as Emacs work.
>
>> Now, do not get me wrong. I am not complaining about these requirements
>> (so, re-reading the Wikipedia entry on "red tape" I guess the term was
>> badly chosen, sorry, not a native speaker; what's a good term for
>> "*lots* of regulation and rigid conformity to formal rules", as opposed
>> to "*excessive*"?), but I do think it's important to keep in mind that
>> these procedures exist. They do exist for various reasons, usually good
>> ones, but they do reduce the appeal of contributing.
>
> If there are better alternatives that are practical, please describe
> them.  Since many other projects of comparable size work like we do, I
> rather doubt there is a good alternative.  And if so, why do we need
> to waste time discussing something that cannot be changed?


The difference between Emacs and GDB is, I think, that GDB is all quite
low-level. Emacs covers a lot more ground from the C guts, to the user
facing code and documentation.

If I ever submit a patch to the C code base, I'd probably expect a lot
of discussion. But, for some parts of Emacs, fire-and-forget is probably
much more reasonable.

So, here are my two alternatives: 

1) Rewrite CONTRIBUTE so that it's info (and thus also webable). Random
   files in etc are only easy to find iff you have a source tarball.

2) Section out CONTRIBUTE, so those wanting to contribute to the easier
   parts don't have to read everything. I think this might help to
   decrease the wall of text experience that it is at the moment.


I'll get to it once I've redone the tutorial which I offered to do a
while back!

Phil