Open Stack

The neutron queens milestone release is held up right now because
some of the repositories are using a release job template that isn't
recognized by the validation code in the releases repository.  I'm
trying to decide between adding the custom job template to the
validation code or changing the release jobs for those neutron
repositories to use the one that isn't custom. I think we'll have
the same problem with horizon plugins using the custom job template
set up for them.

It looks like the publish-to-pypi-neutron template modifies
publish-to-pypi by adding openstack/neutron to the required-repositories
list for the release-openstack-python job. That repository was also at
some point added directly to the release-openstack-python job. So
technically the extension via the template is not needed. The same
applies to publish-to-pypi-horizon.

I see a few issues with keeping job template variants:

1. Having multiple release job variants complicates the release
   repo validation logic. That logic was put in place after we
   discovered several projects without release jobs defined at all,
   so we definitely want to keep some level of validation in place.

2. As we continue to make changes to the release jobs, we're going
   to have to consider whether to make those changes in multiple
   places, which seems error prone.

3. As we find other projects with more dependencies, we're going
   to end up with more custom templates.

Those issues may be mitigated if we move the release job definitions
into the releases repo as we have discussed, because it will be
more obvious that we have multiple related templates that are
variants of one another and we can make the relevant changes all
together in one patch.

One alternative to keeping multiple variants, and defining more in
the future, is to add required-repositories to the release-openstack-python
job directly, as we discover they are needed. Of course that means
we will clone repositories for some jobs that don't actually use
them. I don't know how big of an issue that really is, but the issue
of not knowing which instances of a job actually need a particular
dependency seems like more of a justification for keeping separate
templates than any runtime savings we would have by skipping a
couple of extra calls to git clone.

It feels like we have two related by not necessarily dependent
policy questions we need to answer before we decide how to proceed:

(a) Do we want to move the release job definitions from project-config
    and openstack-zuul-jobs to the releases repo?

(b) Do we want to have multiple release job templates due to custom
    dependencies (or any other reason)?

Thoughts?

Doug