Re: More metaproblem

[Eli Zaretskii <eliz@gnu.org>]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 03 Dec 2014 16:13:55 -0600
> 
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> >For Emacs to attract new developers, its code and the culture need to
> >be discoverable.  As part of this, practice rules need to be *clear*,
> >*documented*, and *minimal*.  Right now they fail all three tests.
> 
> +1 all over that.
> 
> For example, as far as I can see -- and I've looked, though maybe in the
> wrong places -- there's never been a permanent sign anywhere, like on a
> web page, telling developers when they should commit to release branches
> versus when they should commit to master (trunk).

See admin/notes/repo and admin/notes/commits.  What else is missing?

> Sometimes trunk is locked down and most commits are supposed to go to
> the current emacs-NN branch.

Thats a thing of a distant past.  Trunk (a.k.a. "master") is nowadays
never locked, but there are (usually short) periods before a new
release branch is cut, when there's a "feature freeze", i.e. commits
that introduce new features should not be pushed to master.

> Other times it's not locked down.  And you're just supposed to know,
> somehow, I guess by saving random bits of state gleaned from a
> rather high-traffic mailing list.

You need to read this list, yes.  Emacs is not the only project that
uses this practice, though.  GDB is another one.  Publishing such
ephemeral information on the developer's list is an established
practice; posting that on Web pages is IMO worse, because this kind of
information quickly becomes obsolete, and Google searches will then
bring wrong info to people.

> Emacs is not an easy project for newcomers or drive-by contributors.

Which large and complex project _is_ easy for newcomers?

> (And somebody please stop me before I start ranting about debbugs as a
> primary bug tracker even when email-enabled things like Redmine are
> available, since it's been discussed elsewhere.  Apparently for the
> Emacs project in 2014, "send email" is still considered an acceptable UI
> gesture for manipulating a bug ticket.)

I think if you dislike so much in Emacs development practices, you
should become much more active than you are, and then you maybe stand
a chance to start changing all that.