*Release artifact management

We need to discuss when, how and where we upload release artifacts. Specifically: 

	* should we upload server releases to pypi 
	* how should client lib releases work 
	* how does this interface with storyboard 
	* what about if we had a non-python thing?

(Session proposed by Monty Taylor)

-----------------------------------------------------------------------------------

Current state
	* Libraries to Pypi (on releases), sometimes announced
	* Server tarballs (on releases & milestones) to Launchpad
	* Everything also exists in tarballs.o.o

Upload wheels to pypi
	* upload servers and clients (signed uploads are pre-req for this)
	* upload wheels on release and non-release tags
		* pip 1.4 will not find pre-release versions on pypi unless requested
			* how to require pre-release versions?
			* >=1.2.0a1 or pip --pre
			* background: https://github.com/pypa/pip/pull/834
		* older pip will not see wheels
		* wheels don't run python code at install time (arch-dependent binary package format)

TODO (mordred): find out what the deal with server version numbers (release and milestone) wrt pypi, pip, etc.

Server release changes
	* Upload to Pypi ?
		* How to set expectations right (pip install nova will not give you a cloud)
	* Signed uploads (enable download verification for people that would consume tarballs from there)
		* possible solution described in https://launchpad.net/bugs/1118469 (note that title about "md5" is very wrong, that's not a signature, that's a CRC)
		* This is a prerequisite before we would upload server tarballs there
	* http://www.python.org/dev/peps/pep-0440/#date-based-versions
		* http://www.python.org/dev/peps/pep-0440/#final-releases
		* "automated tools SHOULD report an error when encountering a leading release component greater than or equal to 1980"
		* prerequisite action is to check that we can still use human-visible YYYY.S version numbers
	* Start with something like YYYY.S.0 and not just YYYY.S
	* Consider using .xz compression instead of decades old .gz (I'd suggest level 6)
	* Is this all actually a good idea ?
		* Nova is a REST API, not a library
		* Should we encourage consuming Nova as a library ?
			* Sounds like no, but we're not sure that publishing to pypi changes that
			* Make sure we at least add trove classifiers indicating the project is server software, not a library

Library releases changes
	* Streamline announcement format and process
	* Should it be guidelines for a human to follow, or automation ?
	* Need more release notes e.g.
		* http://docs.openstack.org/developer/oslo.config/#id1
	* Step 1: warn relmgr team on release tags
	* Step 1.1: document the common process
	* Step 2: Look into automated release announcement
	* RSS and/or Twitter announcements ?

Future artifact management
	* Should Storyboard include tarballs / release pages ? -> use url
	* Should tarballs.o.o include signatures/verification trail
		* Maybe Pypi will just be enough
	* What about the hypothetical non-Python thing
		* We use pypi for that too (uh?)
		* Might be an argument for implementing a verification trail on tarballs.o.o as well