[dmd-internals] To consume pull requests for trivial bugs

[Maxim Fomin]

Another proposal: introduce beta repository similar to linux-next,
where pull request
may be accepted without full code review. At some time when new
version is being
prepared commits which are considered to be appropriate can be pulled
to official
repository. It doesn't mean that not reviewed patches would get to upstream.
Auto-tester needs to be configured to work with beta too.

Pros:
- addresses out-of-date issue mentioned by Kenji Hara in first message
- "time" test: if patch was in beta tree for several months and
doesn't contain obvious
problems, than it is likely to be correct (assumption here is that
beta is tested enough),
even if this not always hold commits are at least tested by group of
developers for a while
- patches which are sent to upstream are still reviewed as much as necessary, so
  no harm done to upstream code quality
- patches in pull request queue may live for several month, if they
are kept in beta
  tree it is not worse than keeping them in pull requests (and I
believe, actually better)
- commits may be tested not individually, but in large groups within
entire test tree
- if patch is pushed to beta, it forces all participating developers
who sync their
  repositories to test it while working on their projects (as
mentioned, here is
  implicit assumption about sync frequency and something else)
- commits can reviewed not only individually but in groups
- it easier to fix pushed commit than pull request

Cons:
- still need to review
- new problem - resolving conflicts between upstream and beta
- more commits are pushed to beta - more review work
- breaking code may occur in test branch/repo

Anyway, many projects contain beta or "rc" branches/repos. Dmd as I know has
some kind of this but at a limited period of time when making new version. So,
master branch/repo currently plays role of both test and release tree. Why not
split these roles?