Greetings fellow Fedorans!
I am about to start working on a set of backwards incompatible changes to Bodhi for its upcoming 4.0.0 release (Bodhi follows Semantic Versioning[0]):
https://github.com/fedora-infra/bodhi/projects/6
If the thought of backwards incompatible changes to Bodhi raises one or both of your eyebrows, please peruse the list of proposed changes there and comment on any issues that may concern you. I can't be sure who is using Bodhi for what, so please let me know if you think any of these changes are a Bad Idea™.
Greetings fellow Fedorans!
I am about to start working on a set of backwards incompatible changes to Bodhi for its upcoming 4.0.0 release (Bodhi follows Semantic Versioning[0]):
https://github.com/fedora-infra/bodhi/projects/6
If the thought of backwards incompatible changes to Bodhi raises one or both of your eyebrows, please peruse the list of proposed changes there and comment on any issues that may concern you. I can't be sure who is using Bodhi for what, so please let me know if you think any of these changes are a Bad Idea™.
Is there an executive summary as to what's backwards incompatible and what the impact on the average user is? A quick look at the kanban doesn't give me any understanding :)
On Thu, 2018-12-13 at 01:40 +0000, Peter Robinson wrote:
Is there an executive summary as to what's backwards incompatible and what the impact on the average user is? A quick look at the kanban doesn't give me any understanding :)
Each of the issues on the kanban board is a proposal to make a backwards incompatible change. I have not written any summary other than to gather those together in a kanban. Many of them are removing code that I don't believe is used (but that will have an effect on the REST API, or will require admin intervention to upgrade).
Bodhi has many types of users, from release engineers, to admins, to packagers, to integrators, to testers.
Here are some of the proposals I'd draw the most attention to:
* Drop the update title (a list of NVRs that is very buggy) as the Update's primary key, and instead use the update alias (the string that looks like FEDORA-2018-abcde) as the only identifier[0]. * Drop Python 2 support in the client[1] (we will need some dependencies to move to Python 3 to bring this to Rawhide.) * Switch to OpenID Connect[2], which will require backwards incompatible changes in the authentication API and possibly in the Python bindings to the REST API[2]. * Drop anonymous comments[3] - you can't ask follow up questions because anonymous users don't get e-mails. It's not a very useful feature. * Change how the edit APIs work so that a diff is sent rather than the entire set of fields[4]. * Remove critpath karma[5].
[0] https://github.com/fedora-infra/bodhi/issues/1542 [1] https://github.com/fedora-infra/bodhi/issues/2759 [2] https://github.com/fedora-infra/bodhi/issues/1180 [3] https://github.com/fedora-infra/bodhi/issues/2700 [4] https://github.com/fedora-infra/bodhi/issues/2208 [5] https://github.com/fedora-infra/bodhi/issues/2194
On Thu, Dec 13, 2018 at 09:36:09AM -0500, Randy Barlow wrote:
On Thu, 2018-12-13 at 01:40 +0000, Peter Robinson wrote:
Is there an executive summary as to what's backwards incompatible and what the impact on the average user is? A quick look at the kanban doesn't give me any understanding :)
Each of the issues on the kanban board is a proposal to make a backwards incompatible change. I have not written any summary other than to gather those together in a kanban. Many of them are removing code that I don't believe is used (but that will have an effect on the REST API, or will require admin intervention to upgrade).
Bodhi has many types of users, from release engineers, to admins, to packagers, to integrators, to testers.
Here are some of the proposals I'd draw the most attention to:
- Drop the update title (a list of NVRs that is very buggy) as the Update's primary key, and instead use the update alias (the string that looks like FEDORA-2018-abcde) as the only identifier[0].
+1. For big updates the title is completely useless (e.g. kde updates with 100+ packages).
- Drop Python 2 support in the client[1] (we will need some dependencies to move to Python 3 to bring this to Rawhide.)
+1, by the time bodhi 4 is out, a large part of the python2 stack will be gone.
- Switch to OpenID Connect[2], which will require backwards incompatible changes in the authentication API and possibly in the Python bindings to the REST API[2].
Sounds good.
- Drop anonymous comments[3] - you can't ask follow up questions because anonymous users don't get e-mails. It's not a very useful feature.
+1. In my experience those happen much more often because people forget to log in than because they actually want to post anonymously.
- Change how the edit APIs work so that a diff is sent rather than the entire set of fields[4].
- Remove critpath karma[5].
+1. I know it has some uses, adamw recently pointed some out, but I don't think the balance is strongly on the side of not needing that field.
Zbyszek
Il 12/13/18 3:36 PM, Randy Barlow ha scritto:
- Remove critpath karma[5].
I know Fedora wants to move to a more community driven process, but I think the ideas behind adamw proposal [1] of the critpath field are still valid.
I think we could make regular users post regular karma only and provenpackagers/proventesters post critpath karma only (or whatever we decide to name it). The karma of an update would be calculated by the sum of karma + critpath karma, BUT if a negative critpath karma exists, the autopush feature would be disabled (for example, 4 regular users give +1 and a proventester gives -1, the overall karma would be +3 and the threshold for autopush is reached, but the update is not pushed because of proventester feedback).
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Fri, 2018-12-14 at 09:10 +0000, Mattia Verga wrote:
Il 12/13/18 3:36 PM, Randy Barlow ha scritto:
- Remove critpath karma[5].
I know Fedora wants to move to a more community driven process, but I think the ideas behind adamw proposal [1] of the critpath field are still valid.
I'm not opposed to keeping critical path karma if it's believed to be useful.
I think we could make regular users post regular karma only and provenpackagers/proventesters post critpath karma only (or whatever we decide to name it). The karma of an update would be calculated by the sum of karma + critpath karma, BUT if a negative critpath karma exists, the autopush feature would be disabled (for example, 4 regular users give +1 and a proventester gives -1, the overall karma would be +3 and the threshold for autopush is reached, but the update is not pushed because of proventester feedback).
I don't believe we have proven testers anymore, do we? We already disable autopush on any negative karma today - I don't believe we should require a proven packager/tester's negative karma to disable autopusing.
On Thu, 2018-12-13 at 09:36 -0500, Randy Barlow wrote:
- Change how the edit APIs work so that a diff is sent rather than
the entire set of fields[4].
I've made this one a little more expansive - the real problem is that Bodhi's REST API isn't very RESTy - it uses the same URL for creating and editing objects. I plan to make it so you POST to an object's URL to change it, rather than posting to the collection URL with a weird "edited" field in your posted object.
This will certainly break things that edit objects in Bodhi via its REST API. Does anyone know of anything doing that outside of the Bodhi Python bindings?
-
Mattia Verga -
Peter Robinson -
Randy Barlow -
Zbigniew Jędrzejewski-Szmek