elpa.git and `new-master`

[Stefan Monnier]

As part of the effort to setup the NonGNU ELPA infrastructure, I've also
overhauled the GNU ELPA part.

Part of the result is that now all packages are kept on separate
branches (no more "subtree"s).  As a result, the `master` branch has
shrunk significantly..  Especially since even the deployment script
themsevles have moved to a separate branch (`elpa-admin`) so as to be
able to share them between elpa.git and nongnu.git (it also comes with
the side effect that this FSF-copyrighted code is kept in `elpa.git`
rather than `nongnu.git`).

Here are some immediate news linked to this:

- I have now changed elpa.gnu.org to use the new code to build the
  tarballs of GNU ELPA.  Please be on the lookup for any regressions.

- The old `master` branch has shrunk to almost nothing, yet it still
  carries in its history all the code it used to have.  This is not
  a big issue since that code is still around.  More importantly, the
  `master` history includes some entries which Git nowadays considers
  "not quite valid" (resulting in bugs#22690 and bug#25376).
  As a result, I decided to create a fresh `new-master` branch which
  doesn't share its history with `master`.  This new branch will replace
  `master` in the coming days.  So whoever is tracking `master` will be
  faced with a "non-fast-forward" update.
  This can be annoying and I apologize in advance, but I think the
  long terms advantages largely make up for the short term annoyance.

- On the positive side, the new code has some interesting features:
  - It knows how to build Info files from Texinfo files, so we won't need
    to store the generated Info files any more.
  - It also know how to generate Info files from Org manuals.
  - It can even run `make` as part of building the tarballs, making it
    possible to perform various massaging.
    This obviously can't just run "anything you like" since it depends
    on what's available on `elpa.gnu.org`, so if you want to use this
    feature, please get in touch with me so we can coordinate it.
  There is an embryo of documentation of those new features in the
  `README` file in the `elpa-admin` branch.
  This should hopefully make it possible to build a Tramp tarball
  directly from the code in Emacs, or similarly for AUCTeX avoid the
  need to store generated files in Git.
  The `Org` package is an example that uses some of those new features
  to build the tarballs directly from an unadulterated copy of the
  upstream branch.

- Another advantage is that the new code makes it much easier to build
  your own tarballs, for example to test them before pushing to code.
  You can just do `make build/[PKGNAME]` and the resulting package will
  be built in `archive/[PKGNAME]-[VERSION].tar.

- A subtle but important change affects the exact code placed in the
  tarballs.  The old code detected the need to make a new release
  tarball by watching for changes in the `Version:` header and whenever
  it saw a new value, it built the tarball from the HEAD revision.
  The new code detects the need in the same way but will not just use
  the HEAD revision: it will use the specific revision that modified the
  `Version:` header.  This means you can push a commit that bumps the
  `Version:` together with a bunch of subsequent commits that introduce
  wild bleeding edge changes without fearing that the release will
  actually be made from the bleeding edge code.  It also means that if
  you see a remaining bug after you've bumped the `Version:`, there's no
  point quickly pushing a subsequent fix unless you also re-bump the
  `Version:` header.


        Stefan