Thank you for the replies, I have abandon the patches, upon re-review and testing of the case I thought was working I agree that these patches are beyond the scope of what a backport should be.
Chris On Tue, Feb 23, 2016 at 6:22 AM, Heck, Joseph <joseph.h...@emc.com> wrote: > Morning, > > Just a quick note, there is UEFI booting support within iPXE. You have to > invoke a specific build of the binary to get the output, but it's there: > make bin-x86_64-efi/snponly.efi > > Not entirely relevant to the core of the thread, but wanted to share that > detail if it's been otherwise missed. > > - joe > _____________________________ > From: Jim Rollenhagen <j...@jimrollenhagen.com> > Sent: Monday, February 22, 2016 7:37 PM > Subject: Re: [openstack-dev] [ironic] [stable] iPXE / UEFI support for > stable liberty > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > > > > > On Feb 22, 2016, at 15:15, Chris K < nobody...@gmail.com> wrote: > > Hi Ironicers, > > I wanted to draw attention to iPXE / UEFI support in our stable liberty > branch. > > > Which doesn't exist, right? Or does it work depending on some other > factors? > > There are environments that require support for UEFI, while ironic does > have this support in master, it is not capable of this in many > configurations when using the stable liberty release and the docs around > this feature were unclear. > > > What's unclear about the docs? Can you point at a specific thing, or is it > just the lack of a thing that specifically says UEFI+iPXE is not supported? > > Because support for this feature was unclear when the liberty branch was > cut it has caused some confustion to users wishing or needing to consume > the stable branch. I have purposed patches > https://review.openstack.org/#/c/281564 and > https://review.openstack.org/#/c/281536 with the goal of correcting this, > given that master may not be acceptable for some businesses to consume. I > welcome feedback on this. > > > I believe the first patch adds the feature, and the second patch fixes a > bug with the feature. Correct? > > As you know, stable policy is to not backport features. I don't see any > reason this case should bypass this policy (which is why I asked so many > questions above, it's odd to me that this is an open question at all). > > It seems like a better path would be to fix the docs to avoid the > confusion in the first place, right? I'm not sure what the "backport" would > look like, given that docs patch wouldn't make sense on master, but surely > some more experienced stable maintainers could guide us. :) > > // jim > > __________________________________________________________________________ > 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