On 04/03/16 10:24 -0500, Morgan Fainberg wrote:

On Mar 4, 2016 10:16, "Monty Taylor" <[email protected]> wrote:

On 03/04/2016 08:37 AM, Ruby Loo wrote:

Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process'
thread:

        > Should we revert the patch [1] for now? (Disclaimer. I haven't
looked at the
        > patch itself. But I don't think I should have to, to know what the
API
        > change is.)
        >

        Thanks for calling it out Ruby, that's unfortunate that the
        patch was
        merged without the RFE being approved. About reverting the patch I
        think we shouldn't do that now because the patch is touching the API
        and introducing a new microversion to it.


    Exactly. I've -2'ed the revert, as removing API version is even
    worse than landing a change without an RFE approved. Let us make
    sure to approve RFE asap, and then adjust the code according to it.


This brings up another issue, which I recall discussing before. Did we
decide that we'd never revert something that touches the
API/microversion? It might be good to have guidelines on this if we
don't already. IF the API is incorrect? If the API could be improved? If
the API was only in master for eg 48 hours?


I believe you need to treat master as if it's deployed to production. So once
an API change is released, 'fixing' it needs to be done like any other API
change - with a microversion bump and appropriate backwards compat.

(For instance, I have a CI/CD pipeline merging from master every hour and
doing a deploy - so 48 hours is a long time ago)

Monty

So let me jump in here and add in that a direct revert only should happen in
extreme circumstances: aka a change that breaks behavior without a micro
version bump - or something that is causing a break that cannot be fixed easily
rolling forward. (Unable to land code in the gate at all for example, including
roll forward fixes)

In general (and especially with microversions) fail and fix moving forward is
much better for the end users/deployers especially since folks are doing CD
more aggressively now.

There are other considerations but a revert really is one of the most extreme
responses and should be used sparingly.


Just want to +1 the above. Master should be considered as deployed and we
shouldn't assume things. So, I'd advice a proper fix that is also backwards
compatible.

*cough* Doing a change on the API and then a revert feels like releasing on pypi
and then deleting the release. *cough*

Cheers,
Flavio

--
@flaper87
Flavio Percoco

Attachment: signature.asc
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to