[GMG-Devel] State of master, autoconf support

[Christopher Allan Webber]

Hello all,

In the last couple week weeks a number of things changed in MediaGoblin
master.  I gave some warnings that things were unstable, but I didn't
really give an update on what's happened since.  I figured the list
deserved an update.


State of Python 2/3
===================

I announced a few weeks ago that the Python 3 merge was complete, but
that Python 3 was still experimental, and that you should not run it on
your servers at this time.  This is still true, especially because it
does not use the same migration system as Python 2.  This will be worked
on, but is going to take some serious work to figure out how to resolve.

Unfortunately, for a brief period our install docs broke for anyone
running git master.  The problem with this is that our install docs very
foolishly, for *any* release, recommend deploying from git master.  (This
shouldn't be the case, and I'm hoping by the next release, won't be.
More on that below.)  The good news is, git master is now fixed and the
instructions for the last release now work again for installing from
git master.

You can run tests for both python 2 and python 3 by running "tox" (you
will need to install tox of course).  ./runtests.sh will run tests for
only the version you have installed.

If you are having troubles with installing (especially with confusing
messages which talk about "gunicorn"), don't hesitate to talk to us in
#mediagoblin on irc.freenode.net


autoconf support
================

You can now (again) try doing deployment by doing:

  ./bootstrap.sh && ./configure && make

(If you would like to try with python 3 support, you can pass in
--with-python3 to configure)

This will basically replace all the steps up through running the
"virtualenv && setup.py develop" step in our docs.  I don't have docs
that recommend using this strategy, but it should work pretty well I
think.  Testing is encouraged.

If you run into troubles with your virtualenv, you can now also recreate
your virtualenv very easily by doing:

  make clean-virtualenv && make

Everything that is old is new again, and this is especially true
regarding our autoconf support.  Brandon Invergo had done a lot of hard
work to bring autoconf support to MediaGoblin last year, and we got it
integrated.  Unfortunately some users had troubles and at the time I
didn't know how it all worked and I was unable to help them when the
issues came up.  For 0.7.0/0.7.1 I temporarily moved bootstrap.sh to
experimental-bootstrap.sh, but bootstrap.sh is back.

The way things work are substantially different than before, and
pyconfigure is not presently used (it may be again... I would like to
collaborate with Brandon and share the reasons for the changes) but
nonetheless the work Brandon did provided the basis of the present state
of our autoconfigure support, and much of the scaffolding is still in
place.  I do not believe it would be possible for this work to have been
done without Brandon setting down vision to code of what python and gnu
autotools could look like.  Thank you, Brandon!  (I'm hoping we can get
our work to converge soon... I'll try to catch up with you over email
shortly.)

This partly bleeds into the next point...


An end of running from git master soon?
=======================================

Clearly, the HackingHowto should continue to encourage developers to run
from git master, but it is a big mistake that our current docs recommend
that *administrators* do so.  This should be fixed by next release.  One
"stopgap" solution is below, but another is more proper packaging.

MediaGoblin has entered the Debian NEW queue.  It would be great if
people could test out the MediaGoblin Debian package and see how things
work for them!

Likewise, although we do tarball releases, I think nobody ever deploys
from them, and it's not really clear how to do so by our docs.
Likewise, I think though we are on PyPI, I think nobody is using this
package.

Are you interested in helping us test packages?  This is a place where
we could use help!


"stable" branch?
================

I am considering adding a "stable" branch, and having the docs by
default point to this branch.  This will, usually, be whatever the
latest branch is plus maybe a couple of "safe" patches or doc fixes or
whatever that don't merit a new release.  But usually, it will just be
the last release.

If I make this change, I will (for now) set the docs to pull up the
"stable" docs by default, which will always recommend installing the
"stable" git branch.  How do people feel about this?  I feel this could
be a nice stopgap method for making sure people are running well tested
code until we get better packaging in place.


State of federation
===================

Jessica Tallon continues to work hard on federation.  There are some
large challenges on how to nicely structure things database-wise.  If
you're interested in following some of this, I recommend you check out:

  https://theperplexingpariah.co.uk/GMG/mediagoblin_research.html#sec-2-2-2

Likewise, both Jessica and I are now members of the W3C Social Working
Group, working to standardize federation on the web:

  https://www.w3.org/wiki/Socialwg

There will be more on this soon.

I think that's a good summary for now... more coming up soon...
 - Chris