Backwards incompatible changes planned for Bodhi 4.0.0

[Randy Barlow]

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™.


[0] https://semver.org/

[Peter Robinson]

>  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 :)

[Randy Barlow]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Mattia Verga]

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/[e-mail].o...

[Randy Barlow]

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.

[Randy Barlow]

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].
>  
>  
>  [4] https://github.com/fedora-infra/bodhi/issues/2208 
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?