Open Stack

On Mon, Apr 27, 2015, at 11:13 PM, Steve Kowalik wrote:
> Hi,
> 
> 	Monty and I have been discussing Infra building and hosting
> distribution packages that we may require -- things like third-party
> libraries where the distros might lag behind pypi, or where the library
> is not provided by the distro. Which means I'm writing a specification
> for it, and at the moment, there are far too many unanswered questions
> to push up a spec.
> 
> 	I thought I would bring them up here and see if we can reach
> rough consensus, or if we want to defer until Vancouver.
> 
> 
> * Decide where to host said git repositories (or indeed, if we even
> want to), and who should have permissions to approve changes.
Hopefully we can agree to use Gerrit. If we intend on these packages
being reconsumable then using the openstack/ or is probably best. If
they are only intended for our testing maybe openstack-infra? Though
there is some recent thought that we should stop distinguishing orgs all
together like that so maybe just openstack/.

As far as permissions go, I think we can seed the groups with an initial
set of interested individuals then grow from there. Same basic process
for any other new project(s) on Gerrit.
> 
> * Decide if we host full upstream sources, or if we point at a remote
> site with tarballs to extract.
I don't have much of an opinion here other than I think it would be
unfun to maintain local forks of all the things we build packages for. I
am inclined to say point at remote locations until we need to do
otherwise for some reason.
> 
> * Decide how we are going to trigger builds of packages. Per commit may
> not be the most useful step, since committers may want to pull multiple
> disparate changes together into one changelog entry, and hence one
> build.
If a single commit does not produce a useful artifact then it is an
incomplete commit. We should be building packages on every commit, we
may not publish them on every commit but we should build them on every
commit (this is one way to gate for package changes). If we need to
control publishing independent of commits we can use tags to publish
releases. 
> 
> * Decide where to host the resultant package repositories.
> 
> * Decide how to deal with removal of packages from the package
> repositories.
I would like to see us building packages before we worry too much about
hosting them. In the past everyone has want to jump straight to these
problems when we really just need to sort out building packages first.

But if I were to look ahead I would expect that we would run per distro
package mirrors to host our packages and possibly mirror distro released
packages as well.

Hope this helps,
Clark