Open Stack

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 at 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 at 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 at redhat.com>
>> Sent: Thursday, September 26, 2019 9:26 AM
>> To: Julia Kreger
>> Cc: pramchan at yahoo.com; BIN HU; alanmeadows at att.com; jgu at suse.com; openstack-discuss at lists.openstack.org; rg445d at att.com; rp2723 at 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 at 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 at 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