On Mon, Jun 29, 2015 at 11:00 AM, James E. Blair cor...@inaugust.com wrote:
Hi,
Jenkins Job builder is one of our more widely used projects. It has
served us extremely well and a lot of other projects have found it to be
very useful. Many of us are delighted and very proud of this.
Recently I have proposed substantial changes to Zuul that I hope will,
through the process of simplification, mean that we will eventually no
longer need to use JJB in the OpenStack project. However, I believe the
project will continue to be useful for many others. Meanwhile, others
within the JJB community have started proposing major changes to JJB as
well. I wanted to talk about how development might proceed in order to
provide minimal disruption for everyone.
First, I think JJB should continue to at least maintain (and perhaps
enhance) the current use case and syntax we are using in the OpenStack
project infrastructure. If major changes are to happen to JJB, I do not
anticipate that we will want to make use of them in OpenStack, so we
will be a good use case to ensure that we do not break compatibility for
JJB's existing user base.
+1
We should take this one step further and be careful even in cases
where project-config isn't affected by changes. Some of the changes
being discussed in https://review.openstack.org/#/c/194497/ would
definitely have an adverse effect on the configuration I currently
manage.
Having said that, if the Infrastructure Council, including the current
JJB cores, feel that the proposed major changes to JJB are desirable, it
will approve the proposed specs, and those changes can proceed. If the
changes need to break backwards compatibility, we can create a feature
branch for that work (or a stable branch) so that we can continue to
support the current 1.0 syntax (however, if we can evolve JJB in one
branch, all the better).
What about API-specific changes that don't affect DSL or command line behavior?
Initially I was thinking that would happen on a feature branch but I'm
not sure how beneficial that would be at this point.
Finally, assuming that we do accept the Zuulv3 spec and stop using JJB
ourselves, I would expect us to remove JJB from the list of official
OpenStack infrastructure projects, but owing to our responsibility to
the community that has built up around it and our desire for its
continued success, continue hosting development in OpenStack's project
infrastructure as long as we are able and the future JJB development
team desires.
+1, I'd like to help maintain this however I can.
I hope that this sounds like a clear plan that benefits everyone.
Thanks,
Jim
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
