Re: Next release from master

[Alexis <flexibeast@gmail.com>]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Exactly. And developing features on `master' entirely bypasses 
> the "it works" phase, and that is a recipe for disaster. A 
> dangerous change should be on a branch until "it works" (*), 
> then merged to see if it "works right" (**). If the developer 
> recruits some volunteers to see if it "works right" for them 
> before the merge, that's even better.
>
> * An honest "it works", not a "QA is boring, let others do 
> that."
>
> ** Some merges should require an approval by the 
> maintainer. This is no 
>    different from how things are done now. See the cases of the 
>    xwidget branch, the ffi branch...

1+

i would also like to suggest that part of the "it works" phase 
should involve writing (or at least attempting to write) proper 
documentation for the feature(s) involved. Yes, the "works right" 
phase might well involve modifying some of that documentation, but 
proper documentation is important to help people understand how 
the feature is intended to work and/or be used.

Further, it seems to me that Eli is ending up having to write a 
lot of documentation of other people's code, which i feel is 
unfair on him. One of the many things i love about GNU Emacs is 
the comprehensive documentation, which has greatly facilitated my 
ability to customise it and write ELisp packages for use by 
others. If GNU Emacs being "self-documenting" is a headline 
feature, then documentation should be an integral part of code 
development, not Somebody Else's Problem, where "Somebody" is Eli.


Alexis.