)]}'
{"id":"openstack%2Fideas~718929","triplet_id":"openstack%2Fideas~master~I1875855e8accfbb7ff64af1781f0856c12760c11","project":"openstack/ideas","branch":"master","topic":"change-release-cycle","hashtags":[],"change_id":"I1875855e8accfbb7ff64af1781f0856c12760c11","subject":"Project Stopwatch","status":"ABANDONED","created":"2020-04-10 07:32:46.000000000","updated":"2025-10-14 22:23:15.000000000","total_comment_count":0,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"0eccbd1a8f2956c6db42c1990b5262295bbfa364","_number":718929,"virtual_id_number":718929,"owner":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"actions":{},"labels":{"Verified":{"disliked":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"tag":"autogenerated:zuul:check","value":-1,"date":"2020-08-06 09:17:40.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","value":-1,"default_value":0,"optional":true},"Code-Review":{"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"date":"2020-08-06 09:13:10.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"all":[{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"date":"2020-08-06 09:13:10.000000000","permitted_voting_range":{"min":-1,"max":0},"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2020-04-10 09:04:37.000000000","updated_by":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"reviewer":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"state":"REVIEWER"},{"updated":"2020-04-10 14:10:44.000000000","updated_by":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"reviewer":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"state":"REVIEWER"},{"updated":"2020-04-11 08:45:47.000000000","updated_by":{"_account_id":30523,"name":"Dincer Celik","email":"hello@dincercelik.com","username":"osmanlicilegi"},"reviewer":{"_account_id":30523,"name":"Dincer Celik","email":"hello@dincercelik.com","username":"osmanlicilegi"},"state":"REVIEWER"},{"updated":"2020-04-15 13:27:29.000000000","updated_by":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"reviewer":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"state":"REVIEWER"},{"updated":"2020-04-17 08:11:29.000000000","updated_by":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"reviewer":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"state":"REVIEWER"},{"updated":"2020-08-06 09:17:40.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2021-04-19 11:56:47.000000000","updated_by":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"reviewer":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"state":"REMOVED"},{"updated":"2021-06-30 10:33:08.000000000","updated_by":{"_account_id":30523,"name":"Dincer Celik","email":"hello@dincercelik.com","username":"osmanlicilegi"},"reviewer":{"_account_id":30523,"name":"Dincer Celik","email":"hello@dincercelik.com","username":"osmanlicilegi"},"state":"REMOVED"},{"updated":"2023-03-25 20:08:43.000000000","updated_by":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"reviewer":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"state":"REMOVED"}],"messages":[{"id":"73dfa03b2e589acbd3f5bb4e51724e90b985f031","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-10 07:32:46.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"05ac91e52c93a15913a3c31a296a19ac9f495ffd","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-04-10 07:43:07.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/0d9031b4fd384ad8be1eecd6987bd0fe : SUCCESS in 5m 31s","accounts_in_message":[],"_revision_number":1},{"id":"9e9e68fbe6990b7f8ff4194df74e16d3016deea4","author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"date":"2020-04-10 14:10:44.000000000","message":"Patch Set 1:\n\nWhile I think the model is quite neat, and could help some teams, it seems to me too strict. I would prefer we become more liberal rather than less, perhaps suggesting models like this but not mandating them.\n\nIn terms of a coordinated release, what IMO we\u0027re looking for is a release that downstream consumers can consume at a reasonable cadence, knowing that it will be stable and maintained for a period of time.\n\nI would rather see a simple, liberal model where teams are free to release as they wish, and periodically one recent release will be promoted to a stable release, for inclusion in a coordinated OpenStack release. A branch would be cut at that point for patch releases.","accounts_in_message":[],"_revision_number":1},{"id":"8bd2644fe18234f443b700fef1431bd4f17e257f","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-12 08:36:26.000000000","message":"Patch Set 1:\n\n\u003e While I think the model is quite neat, and could help some teams,\n \u003e it seems to me too strict. I would prefer we become more liberal\n \u003e rather than less, perhaps suggesting models like this but not\n \u003e mandating them.\n \u003e \n \u003e In terms of a coordinated release, what IMO we\u0027re looking for is a\n \u003e release that downstream consumers can consume at a reasonable\n \u003e cadence, knowing that it will be stable and maintained for a period\n \u003e of time.\n \u003e \n \u003e I would rather see a simple, liberal model where teams are free to\n \u003e release as they wish, and periodically one recent release will be\n \u003e promoted to a stable release, for inclusion in a coordinated\n \u003e OpenStack release. A branch would be cut at that point for patch\n \u003e releases.\n\nThat sounds to me like the description of the \"independent\" part in this proposal. Basically extending the current \"independent\" tooling would allow the flexibility the projects need.\n\nThis takes a conservative approach for projects which need the conservative approach.\n\nI agree that \"being more lax\" is probably the way to go forward.","accounts_in_message":[],"_revision_number":1},{"id":"42e43ad49e30f01235363a8fcf92ecbb33bc1fd8","author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"date":"2020-04-15 13:27:29.000000000","message":"Patch Set 1:\n\nThe proposal is based on the predicate that having a feature freeze every 6 months puts too much pressure on getting things in the coordinated release (the one that has a stable branch). The issue is that the solution presented still has a special feature freeze every 6 months to get things in the coordinated release (the one that has a stable branch). There will still be one too-important-to-miss feature freeze every 6 months, just like today. So I fail to see how adding less-important feature freezes every 2 months is going to reduce pressure and work. \n\nThis proposal is also based on the idea that you simplify by proposing only two models: one very constrained tick-tock model (with much more constraints than the current cycle-with-rc model), and the independent model for those who can\u0027t have that many constraints (or do not produce anything in 4 months, which is now quite common). The issue I have with this is that the \"independent\" model is... independent of the coordinated cycle. It means that deliverables under that model do not produce stable branches every cycle, and that they are not tested together with other deliverables using the same cycle-based stable branches. That\u0027s why we currently enforce that all OpenStack \"IaaS\" services follow the release model tied to the cycle (can\u0027t be independent). I feel that pushing services to use an independent model would be a significant regression.","accounts_in_message":[],"_revision_number":1},{"id":"5b16a464210d2dcb55626f79af9fdc72da6bcbb8","author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"date":"2020-04-16 09:23:55.000000000","message":"Patch Set 1:\n\n\u003e I would rather see a simple, liberal model where teams are free to release as they wish, and periodically one recent release will be promoted to a stable release, for inclusion in a coordinated OpenStack release. A branch would be cut at that point for patch releases.\n\nI was thinking among the same lines: a bunch of releases, some of them spawning semi-stable branches (at the discretion of a team). And a final coordinated release of all projects once a year with long-term support.\n\nI haven\u0027t read the proposal in question yet, answering the comments first (yes, I\u0027m weird).","accounts_in_message":[],"_revision_number":1},{"id":"3031b8492d0f73466d058b9bbbab157c8974e638","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-16 11:54:18.000000000","message":"Patch Set 1:\n\n\u003e \u003e I would rather see a simple, liberal model where teams are free\n \u003e to release as they wish, and periodically one recent release will\n \u003e be promoted to a stable release, for inclusion in a coordinated\n \u003e OpenStack release. A branch would be cut at that point for patch\n \u003e releases.\n \u003e \n \u003e I was thinking among the same lines: a bunch of releases, some of\n \u003e them spawning semi-stable branches (at the discretion of a team).\n \u003e And a final coordinated release of all projects once a year with\n \u003e long-term support.\n \u003e \n \u003e I haven\u0027t read the proposal in question yet, answering the comments\n \u003e first (yes, I\u0027m weird).\n\nThat\u0027s kinda where I am headed with the \u0027independent\u0027 part of the model.\nPeople can spawn up their branches, do their tagging. The release team deals with the tooling and consistent expectations for users.\n\nHowever, the independent model still stays out of the \"coordinated release\" in my example. This is because I trust CI to be a better contract of coordination than anything else really. So for me, I want to move, in the future to claim that the coordinated release is merely a tag on top of independent deliverables (which can be asserted by CI basically).","accounts_in_message":[],"_revision_number":1},{"id":"346a86bb1fb1b8f8eb9081a052c9c59163c1d0b2","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-16 12:02:50.000000000","message":"Patch Set 1:\n\n\u003e The proposal is based on the predicate that having a feature freeze\n \u003e every 6 months puts too much pressure on getting things in the\n \u003e coordinated release (the one that has a stable branch).\n\nThat\u0027s correct, it\u0027s an issue I heard many times.\n\n \u003e The issue\n \u003e is that the solution presented still has a special feature freeze\n \u003e every 6 months to get things in the coordinated release (the one\n \u003e that has a stable branch).\n\nIt does not require a big major feature freeze, nor have the checkpoints.\nPeople can still work on features. It imposes a rythm to the contributors to avoid a burnout effect.\n\n \u003e There will still be one\n \u003e too-important-to-miss feature freeze every 6 months, just like\n \u003e today. So I fail to see how adding less-important feature freezes\n \u003e every 2 months is going to reduce pressure and work.\n\nIt forces the community to think differently about freezes, and that\u0027s one of the gaps we have to fight, IMO.\n\n \u003e \n \u003e This proposal is also based on the idea that you simplify by\n \u003e proposing only two models: one very constrained tick-tock model\n \u003e (with much more constraints than the current cycle-with-rc model),\n \u003e and the independent model for those who can\u0027t have that many\n \u003e constraints (or do not produce anything in 4 months, which is now\n \u003e quite common). The issue I have with this is that the \"independent\"\n \u003e model is... independent of the coordinated cycle.\n\nDo you think it would make sense to drop the tick-tock, and just go for independent for everyone?\n\n \u003e It means that\n \u003e deliverables under that model do not produce stable branches every\n \u003e cycle, and that they are not tested together with other\n \u003e deliverables using the same cycle-based stable branches.\n\nAsserting to be one or the other doesn\u0027t change how testing is made, isn\u0027t it?\nThat was the whole point of the tick-tock model: We force some kind of cadence, to have a migration path forward to independent deliverables which have a way to ensure co-installability.\n\n \u003e That\u0027s why\n \u003e we currently enforce that all OpenStack \"IaaS\" services follow the\n \u003e release model tied to the cycle (can\u0027t be independent). I feel that\n \u003e pushing services to use an independent model would be a significant\n \u003e regression.\n\nI am pretty sure this model won\u0027t please everyone. However, I am trying to move and change things, where it doesn\u0027t seem to work.\n\nThis proposal intends to be more flexible in terms of releasing, improving the freedom of the projects, and provides a path to ensure co-installability that _at the same time_ could reduce the pressure on PTLs. \n\nAll suggestions (or improvements) on this are welcome :)","accounts_in_message":[],"_revision_number":1},{"id":"002115c151736e29d378a001f2a995d15d3b7bd9","author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"date":"2020-04-16 12:03:29.000000000","message":"Patch Set 1:\n\n\u003e However, the independent model still stays out of the \"coordinated release\" in my example.\n\nWell, this means that ironic would stay out of the coordinated release, which is something that people are trying to avoid, as far as I understand.","accounts_in_message":[],"_revision_number":1},{"id":"25e29b37c42b7b9a5299017a21f55e9fda0de07e","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-16 12:07:26.000000000","message":"Patch Set 1:\n\n\u003e \u003e However, the independent model still stays out of the\n \u003e \"coordinated release\" in my example.\n \u003e \n \u003e Well, this means that ironic would stay out of the coordinated\n \u003e release, which is something that people are trying to avoid, as far\n \u003e as I understand.\n\nI am fine with ironic being out of the coordinated release tbh.\nWhat I would be less fine/more sad is ironic getting out of the OpenStack project for a wrong reason ;)\n\nIt\u0027s different to be part of the coordinated release and be an official project. I can discuss that in another media than this review though :)","accounts_in_message":[],"_revision_number":1},{"id":"d39a25fe046cc51b03e9947a4687e7f724039410","author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"date":"2020-04-16 12:12:23.000000000","message":"Patch Set 1:\n\nI don\u0027t see what will be left of ironic\u0027s participation in OpenStack if we even stop being parts of coordinated releases (and thus e.g. gate against other components in the same way we do now).","accounts_in_message":[],"_revision_number":1},{"id":"82f16160170b2bcc304a1ae5cafb0874167d7e3a","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-17 07:11:36.000000000","message":"Patch Set 1:\n\n\u003e I don\u0027t see what will be left of ironic\u0027s participation in\n \u003e OpenStack if we even stop being parts of coordinated releases (and\n \u003e thus e.g. gate against other components in the same way we do now).\n\nYou would still be an openstack project. It means that Ironic _can_ still be co-tested/integrated easily, but also:\n- Ensures you\u0027re following the PTI (this way you won\u0027t break non-standalone users)\n- Ensures you have a consistent user interface with other projects\n- Ensure you can benefit from the tooling from the rest of the community, like releases, infra, etc.\n\nIt makes me real sad to see we are at a point where people don\u0027t see the value of being an official OpenStack project. This is dividing instead of multipling. But I will shut up now, I am probably an old fart :p","accounts_in_message":[],"_revision_number":1},{"id":"46f1b1d85e292f66d7e9233750456f51c8f29506","author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"date":"2020-04-17 08:11:29.000000000","message":"Patch Set 1:\n\nSorry, but I have to disagree on all three points:\n\n\u003e Ensures you\u0027re following the PTI (this way you won\u0027t break non-standalone users)\n\nThis is ensured by our general sanity, not by our membership in OpenStack.\n\n\u003e Ensures you have a consistent user interface with other projects\n\nLiterally nothing ensures this right now. API SIG has never received enough traction, there is no consistency effort for OSC plugins, microvesions did not become universal (nor neutron-style extensions) and only openstacksdk is trying, but there is no global move to replace clients with it.\n\n\u003e Ensure you can benefit from the tooling from the rest of the community, like releases, infra, etc.\n\nWe\u0027d still use the same infra, only some of the releases tooling would be missing (and for independent projects it\u0027s of little help anyway).","accounts_in_message":[],"_revision_number":1},{"id":"d30658565d3378f0a09147c75d1a6bace3ece293","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-04-17 14:29:13.000000000","message":"Patch Set 1:\n\n\u003e Sorry, but I have to disagree on all three points:\n\nThat makes it an interesting conversation, isn\u0027t it? :p \n\n \u003e \n \u003e \u003e Ensures you\u0027re following the PTI (this way you won\u0027t break\n \u003e non-standalone users)\n \u003e \n \u003e This is ensured by our general sanity, not by our membership in\n \u003e OpenStack.\n\nI don\u0027t disagree that sanity makes us chose the versions, but the membership in openstack ensures it. That\u0027s why the PTI was meant for. But yeah, it\u0027s about a set of expectations, not code.\n\n \u003e \n \u003e \u003e Ensures you have a consistent user interface with other projects\n \u003e \n \u003e Literally nothing ensures this right now. API SIG has never\n \u003e received enough traction, there is no consistency effort for OSC\n \u003e plugins, microvesions did not become universal (nor neutron-style\n \u003e extensions) and only openstacksdk is trying, but there is no global\n \u003e move to replace clients with it.\n\nThere was multiple efforts (and there are still continued efforts) to have OSC as the single consistent CLI.\nI agree it has limited success. But it is probably more consistent than if it was the wild west, don\u0027t you think?\n\n \u003e \n \u003e \u003e Ensure you can benefit from the tooling from the rest of the\n \u003e community, like releases, infra, etc.\n \u003e \n \u003e We\u0027d still use the same infra, only some of the releases tooling\n \u003e would be missing (and for independent projects it\u0027s of little help\n \u003e anyway).\n\nMy proposal highlights the benefits for the independent model.\n\nI think that now we are discussing the fundamentals of the idea.\nShould we merge the idea as it is right now, and just iterate over it, by mentioning that this was proposed and not really well accepted? I have the impression if we do it, we\u0027re gonna be able to improve the idea to match what more folks are needing.","accounts_in_message":[],"_revision_number":1},{"id":"53a9c6c3cc7d440c6a9ffce9ec7580c91e132b6f","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-06-18 10:05:01.000000000","message":"Patch Set 2: Published edit on patch set 1.","accounts_in_message":[],"_revision_number":2},{"id":"ef8be60bb5b14a0b9389dcc3347b3813f064b18f","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-06-18 10:15:10.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/326ab20284a640c58eec203115b8fe52 : SUCCESS in 3m 33s","accounts_in_message":[],"_revision_number":2},{"id":"281cead3c0a68176c4d9b46fccaba0cbf7daa242","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-08-06 09:10:45.000000000","message":"Patch Set 2:\n\nI think we can merge that.","accounts_in_message":[],"_revision_number":2},{"id":"dc19287a8ef68dd171c1e4600b9b148dbfd906e6","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-08-06 09:12:35.000000000","message":"Patch Set 3: Published edit on patch set 2.","accounts_in_message":[],"_revision_number":3},{"id":"93847ae22707b8d913381dc7b4325362525ffe54","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-08-06 09:13:10.000000000","message":"Patch Set 3: Code-Review+2 Workflow+1\n\nI am merging the idea.","accounts_in_message":[],"_revision_number":3},{"id":"5cfc86477df49300b65c4f829407e00c57c2c340","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-08-06 09:17:40.000000000","message":"Patch Set 3: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\n\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/7f6119647b77436fa1c9463b061bbe9b : FAILURE in 3m 30s","accounts_in_message":[],"_revision_number":3},{"id":"4ba23af02ab5a6eb7e4c2654f0a8d44bfcdc1d2a","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-08-07 14:20:13.000000000","message":"Removed Workflow+1 by Jean-Philippe Evrard \u003cjean-philippe@evrard.me\u003e\n","accounts_in_message":[],"_revision_number":3},{"id":"534d7617962a543479fa6651a031552ae061dece","author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"date":"2020-08-07 14:20:22.000000000","message":"Removed Code-Review+2 by Jean-Philippe Evrard \u003cjean-philippe@evrard.me\u003e\n","accounts_in_message":[],"_revision_number":3},{"id":"de79b6b7dab9f54381acddb1cd63131a2fce4cd2","tag":"autogenerated:gerrit:deleteReviewer","author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"date":"2021-04-19 11:56:47.000000000","message":"Removed reviewer Thierry Carrez.","accounts_in_message":[],"_revision_number":3},{"id":"ed57745457fb3b183bced3d0ceeb49bdddbf5ec5","tag":"autogenerated:gerrit:deleteReviewer","author":{"_account_id":30523,"name":"Dincer Celik","email":"hello@dincercelik.com","username":"osmanlicilegi"},"date":"2021-06-30 10:33:08.000000000","message":"Removed reviewer Dincer Celik.","accounts_in_message":[],"_revision_number":3},{"id":"c49c1650263eb5f02aac64ee15e15e72d419c071","tag":"autogenerated:gerrit:deleteReviewer","author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"date":"2023-03-25 20:08:43.000000000","message":"Removed reviewer \u003cGERRIT_ACCOUNT_30491\u003e.","accounts_in_message":[{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"}],"_revision_number":3},{"id":"0eccbd1a8f2956c6db42c1990b5262295bbfa364","tag":"autogenerated:gerrit:abandon","author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"date":"2025-10-14 22:23:15.000000000","message":"Abandoned\n\nThis change hasn\u0027t seen any activity for 2025 calendar year.  Abandoning on behalf of the OpenStack Technical Committee.\n\nIf you believe this work is still valid, please reopen and refresh.","accounts_in_message":[],"_revision_number":3}],"current_revision_number":3,"current_revision":"f6b7c8c1d8bdd7116af79c92d8336e77192a2a5f","revisions":{"19ffd9ab56f2208879ddb3512d5751d8ebb582c6":{"kind":"REWORK","_number":1,"created":"2020-04-10 07:32:46.000000000","uploader":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"ref":"refs/changes/29/718929/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/ideas","ref":"refs/changes/29/718929/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/ideas refs/changes/29/718929/1"}}},"commit":{"parents":[{"commit":"6f33f3225748e702aafcd1d2601b346f2b2b0f78","subject":"Merge \"Add Project Teapot idea\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/6f33f3225748e702aafcd1d2601b346f2b2b0f78"}]}],"author":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-04-06 16:40:49.000000000","tz":120},"committer":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-04-10 07:32:31.000000000","tz":120},"subject":"Project Stopwatch","message":"Project Stopwatch\n\nThis is a proposal to change our release cycles, simplifying\nour procedures.\n\nChange-Id: I1875855e8accfbb7ff64af1781f0856c12760c11\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/19ffd9ab56f2208879ddb3512d5751d8ebb582c6"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/19ffd9ab56f2208879ddb3512d5751d8ebb582c6"}]},"branch":"refs/heads/master"},"3772f28874148f9e761124be95097f95c800aca8":{"kind":"REWORK","_number":2,"created":"2020-06-18 10:05:01.000000000","uploader":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"ref":"refs/changes/29/718929/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/ideas","ref":"refs/changes/29/718929/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/ideas refs/changes/29/718929/2"}}},"commit":{"parents":[{"commit":"6f33f3225748e702aafcd1d2601b346f2b2b0f78","subject":"Merge \"Add Project Teapot idea\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/6f33f3225748e702aafcd1d2601b346f2b2b0f78"}]}],"author":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-04-06 16:40:49.000000000","tz":120},"committer":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-06-18 10:04:59.000000000","tz":0},"subject":"Project Stopwatch","message":"Project Stopwatch\n\nThis is a proposal to change our release cycles, simplifying\nour procedures.\n\nChange-Id: I1875855e8accfbb7ff64af1781f0856c12760c11\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/3772f28874148f9e761124be95097f95c800aca8"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/3772f28874148f9e761124be95097f95c800aca8"}]},"branch":"refs/heads/master"},"f6b7c8c1d8bdd7116af79c92d8336e77192a2a5f":{"kind":"REWORK","_number":3,"created":"2020-08-06 09:12:35.000000000","uploader":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"ref":"refs/changes/29/718929/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/ideas","ref":"refs/changes/29/718929/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/ideas refs/changes/29/718929/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/ideas refs/changes/29/718929/3"}}},"commit":{"parents":[{"commit":"6f33f3225748e702aafcd1d2601b346f2b2b0f78","subject":"Merge \"Add Project Teapot idea\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/6f33f3225748e702aafcd1d2601b346f2b2b0f78"}]}],"author":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-04-06 16:40:49.000000000","tz":120},"committer":{"name":"Jean-Philippe Evrard","email":"jean-philippe@evrard.me","date":"2020-08-06 09:12:32.000000000","tz":0},"subject":"Project Stopwatch","message":"Project Stopwatch\n\nThis is a proposal to change our release cycles, simplifying\nour procedures.\n\nChange-Id: I1875855e8accfbb7ff64af1781f0856c12760c11\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/f6b7c8c1d8bdd7116af79c92d8336e77192a2a5f"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/ideas/commit/f6b7c8c1d8bdd7116af79c92d8336e77192a2a5f"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[{"name":"Verified","description":"Verified in gate by CI","status":"UNSATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Verified\u003dMAX AND -label:Verified\u003dMIN","fulfilled":false,"status":"FAIL","passing_atoms":[],"failing_atoms":["label:Verified\u003dMAX","label:Verified\u003dMIN"],"atom_explanations":{}}},{"name":"Code-Review","description":"Code reviewed by core reviewer","status":"UNSATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Code-Review\u003dMAX AND -label:Code-Review\u003dMIN","fulfilled":false,"status":"FAIL","passing_atoms":[],"failing_atoms":["label:Code-Review\u003dMAX","label:Code-Review\u003dMIN"],"atom_explanations":{}}},{"name":"Workflow","description":"Approved for gate by core reviewer","status":"UNSATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Workflow\u003dMAX AND -label:Workflow\u003dMIN","fulfilled":false,"status":"FAIL","passing_atoms":[],"failing_atoms":["label:Workflow\u003dMAX","label:Workflow\u003dMIN"],"atom_explanations":{}}}]}