On 08/21/2017 05:44 PM, Doug Hellmann wrote:
Excerpts from Sam Betts (sambetts)'s message of 2017-08-21 10:01:35 +0000:
Quick reply with my thoughts in-line.
Sam
On 21/08/2017, 10:13, "Dmitry Tantsur" <dtant...@redhat.com> wrote:
(adding the release and stable team just for their information)
Thanks Julia and everyone for handling this situation while I was out. More
comments inline.
On 08/17/2017 07:13 PM, Julia Kreger wrote:
> Greetings everyone!
>
> As some of you may have noticed, we released ironic 9.0.0 today. But
> wait! There is more!
>
> We triggered this release due to a number of issues, one of which was
> that we learned that we needed the stable/pike branch for our grenade
> jobs to execute properly. This was not done previously because
> Ironic’s release model is incompatible with making release candidate
> releases.
Yep :( So, I think the lesson to learn is to create our stable/XXX branch at the
same time as the other projects. We kind of knew that already, but did not
anticipate such a huge breakage so quickly. I suggest we don't try it in
Queens :)
Yes, we do try to encourage teams to branch around that RC1 period when
the milestone-based projects branch to avoid these sorts of issues.
Now, with that in place we still have two options:
1. A conservative one - make the branching the hard feature freeze,
similar to
other projects. We may start with a soft freeze at around M3, and just
move into
Queens when stable/queens is created. As that point, what is out - is out.
2. Alternative - continue making selected feature backports until the final
freeze roughly one week before the final release. This kind of contradicts
calling a branch "stable" though.
I see that Ironic didn't really take advantage of the
cycle-with-intermediary model by preparing any intermediary releases
during pike, so perhaps it would be simplest to change the release
model to cycle-with-milestones and align with the other projects
that way?
This may be an option, though I personally don't see much value in doing
milestone beta releases compared to intermediary ones.
The problem with this cycle was that we tries to land several huuuuge features,
and we did not want to release them unfinished. There are some strong voices in
the community to avoid such situation in Queens.
In any case, we'll discuss it on the PTG, and will consider your proposal too.
I don't have a strong opinion, but I'm slightly more in favor of the
conservation option #1 to avoid confusing people and complicating the
process.
Thoughts?
Personally, I think option 2 still makes sense, and it aligns us closely with
the process in the other projects, the difference between us and them is that
their branch is cut using a release candidate instead of a real release. The
act of backporting things into the stable branch and then re-releasing is the
same though.
Another alternative I wonder if we should consider is cutting our branch
earlier in the cycle, when we make our first intermediary release, and then
finding out if we can sync the branches at each release time instead of
backporting everything. E.g. git checkout stable/X, git reset –hard
origin/master or git rebase master, git push. Doing this will allow us to
retain the git history and same commit ids from master to stable/X until master
stops developing stable/X and moves on to stable/X+1. I think another advantage
of this is it also allows people to find and use our latest intermediary
releases easier. But I don’t know how nicely this would work with all the
tooling etc the release team has in place.
I don't think that is something the release team would be prepared
to support. We're trying to avoid having every project handling
releases and branches in their own way, because it makes tooling
that much harder to deal with.
+1 to this, I don't think we should become too creative :)
>
> Once we’ve confirmed that our grenade testing is passing, we will back
> port patches we had previously approved, but that had not landed, from
> master to stable/pike.
++ I've approved a few patches already, and will continue approving them today.
>
> As a result, please anticipate Ironic’s official Pike release for this
> cycle to be 9.1.0, if the stars, gates, and job timeouts align with
> us.
Right, I think we will request it on Wednesday, to allow a bit more time to test
our newly populated not-so-stable stable/pike :)
>
> If there are any questions, please feel free to stop by
> #openstack-ironic. We have also been keeping our general purpose
> whiteboard[1] up to date, you can see our notes regarding our current
> plan starting at line 120, and notes regarding gate failures and
> issues starting at line 37.
> Thanks!
>
> -Julia
>
> [1]: https://etherpad.openstack.org/p/IronicWhiteBoard
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
