<div dir="ltr">Hi,<br><div><br>Bit slow in catching up with email<br><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2015 at 16:44, Wayne Warren <span dir="ltr"><<a href="mailto:wayne@puppetlabs.com" target="_blank">wayne@puppetlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 29, 2015 at 11:00 AM, James E. Blair <<a href="mailto:corvus@inaugust.com">corvus@inaugust.com</a>> wrote:<br>
> Hi,<br>
><br>
> Jenkins Job builder is one of our more widely used projects.  It has<br>
> served us extremely well and a lot of other projects have found it to be<br>
> very useful.  Many of us are delighted and very proud of this.<br>
><br>
> Recently I have proposed substantial changes to Zuul that I hope will,<br>
> through the process of simplification, mean that we will eventually no<br>
> longer need to use JJB in the OpenStack project.  However, I believe the<br>
> project will continue to be useful for many others.  Meanwhile, others<br>
> within the JJB community have started proposing major changes to JJB as<br>
> well.  I wanted to talk about how development might proceed in order to<br>
> provide minimal disruption for everyone.<br></span></blockquote><div> <br></div><div>Would be interested in learning more about the proposed Zuul changes, would you mind pointing me towards some of the discussions. I'm assuming that anyone else interested in the internals of JJB's parsing/expansion would like to see if anything can be learnt from what you are doing with Zuul.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> First, I think JJB should continue to at least maintain (and perhaps<br>
> enhance) the current use case and syntax we are using in the OpenStack<br>
> project infrastructure.  If major changes are to happen to JJB, I do not<br>
> anticipate that we will want to make use of them in OpenStack, so we<br>
> will be a good use case to ensure that we do not break compatibility for<br>
> JJB's existing user base.<br>
<br>
</span>+1<br>
<br>
We should take this one step further and be careful even in cases<br>
where project-config isn't affected by changes. Some of the changes<br>
being discussed in <a href="https://review.openstack.org/#/c/194497/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/194497/</a> would<br>
definitely have an adverse effect on the configuration I currently<br>
manage.<br></blockquote><div><br></div><div>I would be hopeful that we can put any breaking changes behind config options at least until ready to issue a new major release, ideally with the ability to revert to the old behaviour via the config option. <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Having said that, if the Infrastructure Council, including the current<br>
> JJB cores, feel that the proposed major changes to JJB are desirable, it<br>
> will approve the proposed specs, and those changes can proceed.  If the<br>
> changes need to break backwards compatibility, we can create a feature<br>
> branch for that work (or a stable branch) so that we can continue to<br>
> support the current 1.0 syntax (however, if we can evolve JJB in one<br>
> branch, all the better).<br>
<br>
</span>What about API-specific changes that don't affect DSL or command line behavior?<br>
<br>
Initially I was thinking that would happen on a feature branch but I'm<br>
not sure how beneficial that would be at this point.<br></blockquote><div><br></div><div>The current API changes proposed, if that's all that change, won't impact existing usage provided it's via the command line. So should be safe there if we can implement them behind some config options.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Finally, assuming that we do accept the Zuulv3 spec and stop using JJB<br>
> ourselves, I would expect us to remove JJB from the list of official<br>
> OpenStack infrastructure projects, but owing to our responsibility to<br>
> the community that has built up around it and our desire for its<br>
> continued success, continue hosting development in OpenStack's project<br>
> infrastructure as long as we are able and the future JJB development<br>
> team desires.<br>
<br>
</span>+1, I'd like to help maintain this however I can.<br></blockquote><div><br></div><div> Plan to keep helping here as well :)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
> I hope that this sounds like a clear plan that benefits everyone.<br>
><br>
> Thanks,<br>
><br>
> Jim<br></div></div></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool"</div>
</div></div></div>