I think the bottom line ends up being "are things ready" by the time we need to cut the stable branch for the train cycle release product.
In this case, it was not ready with the required reviews. We should not thus back-port it unless there is a seriously compelling case or reason with substantial community support. We've had to backport major patches at the last minute before, but that was _ONLY_ when CI was completely broken and those patches were required to fix CI and have a functional release.
In other words. I'm not going to force or approve it. In fact, at this point, I think stable policy stands for the stable/* branches, and we need to accept that it didn't manage to make it on the train when the train had to be shipped. I only suggested that we even consider the patch because I didn't see a 13.0.0 release patch already proposed when I reviewed the email and reviewed the patch being proposed for review.
-Julia
On Thu, Sep 26, 2019 at 8:34 AM Dmitry Tantsur dtantsur@redhat.com wrote:
We can and should revisit any rules we impose on ourselves from time to time. However, this one should not be taken lightly. And the stable branch policy applies openstack-wide. We can opt out it, of course, but let us keep in mind the implications it has for consumers that expect stable branches to be, well, stable.
Note that we don't really have a lot of asks for FFE. The one in question was not ready by the time an FFE was appropriate (i.e. on the day of FF +/- a couple of days). We have already been quite relaxed with a few patches that had been ready by the FF date (and got delayed partly because of the CI state).
Speaking of which, if we could get more help with daily things, we could free up more time to review patches. And the CI wouldn't block them from merging. Just... saying ;)
Best, Dmitry
On Thu, Sep 26, 2019 at 5:07 PM Arkady.Kanevsky@dell.com wrote:
Understandable.
But we have a rule that we do not backport “new” functionality.
That puts pressure on many asks for FFE.
Should we revisit that rule a bit?
From: Dmitry Tantsur dtantsur@redhat.com Sent: Thursday, September 26, 2019 9:26 AM To: Julia Kreger Cc: pramchan@yahoo.com; BIN HU; alanmeadows@att.com; jgu@suse.com; openstack-discuss@lists.openstack.org; rg445d@att.com; rp2723@att.com Subject: Re: [ironic] FFE: Add idrac HW type Redfish virtual media boot interface (Ruby Loo)
[EXTERNAL EMAIL]
On Thu, Sep 26, 2019 at 2:38 PM Julia Kreger juliaashleykreger@gmail.com wrote:
I’m afraid 13.0.0 has been released which is what we targeted to release for Train.
Is there any reason Ironic can’t release 13.1.0 in say a month? I ask since there should be no hard requirement with Ironic in starting with the stable/train branch.
The reason is the stable policy. We've committed to following it, and it doesn't allow feature backports.
An important detail is Airship 2.0 slated for release. If we’re trying to co-ordinate everything across communities, that seems like it is going to be very problematic.
It would be ideal if such requirements could be determined a bit in advance, not later than M3.
Dmitry
-Julia
On Wed, Sep 25, 2019 at 5:15 PM prakash RAMCHANDRAN pramchan@yahoo.com wrote:
Julia & Richard,
We in airship 2.0 need vIrtual media boot up for our work in remoteboot direct using Ironic redfish interface. This is to use both for Ehemeral BareMetalHost as well for target cluter BareMetal Nodes redfish based Virtual Media booting.
We in Airship community strongly endorse the exception to include this feature in Train.
I am copying few of our TC & WC members who too can confirm my ask on behalf of Airship 2.0 team.
Thanks
Prakash Ramchandran
(pramchan)
Sent from Yahoo Mail on Android