#806 Retire Long Life to Pagure badges
Merged 2 years ago by gui1ty. Opened 3 years ago by oturpe.
oturpe/fedora-badges retire-pagure-long-life  into  master

Retire Long Life to Pagure badges
Otto Urpelainen • 3 years ago  
retired_rules/pagure-long-life-01.yml rules/pagure-long-life-01.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure I)

retired_rules/pagure-long-life-10.yml rules/pagure-long-life-10.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once.

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure II)

retired_rules/pagure-long-life-1000.yml rules/pagure-long-life-1000.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once.

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure VI)

retired_rules/pagure-long-life-150.yml rules/pagure-long-life-150.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once.

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure IV)

retired_rules/pagure-long-life-50.yml rules/pagure-long-life-50.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once.

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure III)

retired_rules/pagure-long-life-500.yml rules/pagure-long-life-500.yml
file renamed
+6
@@ -1,5 +1,11 @@ 

  %YAML 1.2

  ---

+ # Retired due to the following issues:

+ # 1. If the message contains commits from multiple authors, commits count per

+ #    author is not available.

+ # 2. Even if commit count per author was available, there is no way to evaluate

+ #    criteria separately for each author.

+ # 3. Synchronizing forks leads to the same commits being counted more than once.

  

  # This is some metadata about the badge

  name:           Long Life to Pagure (Pagure V)

These badges do not work as they should for the following reasons:

  1. If the message contains commits from multiple authors, commits count per author is not available.
  2. Even if commit count per author was available, there is no way to evaluate the criteria separately for each author.
  3. Rebasing in forks leads to the same commits being counted more than once, without the badge recipient actually doing anything themself.

Item 1 could be solved by simple extension of schema so that Pagure would include the count per author. If it was the only problem, there would be no need to retire these rules.

Item 2 has the worst effect by far. It has lead to many users having the highest level badge only because they happened to appear as an author in a message that also included a prominent committer. Fixing it would require extension of the rules language in fedbadges backend. It is unclear how difficult that would be.

Item 3 would require more changes to messages emitted by Pagure. A way to distinguish between original work and it being reapplied by others would be needed. Perhaps comparing 'agent' and 'author' would work. But it is unclear if fedbadges backend allows such expressions.

All in all, the rules for Pagure badges are specified in a way that is difficult to implement correctly. Since currently badges are awarded to users that have not earned them and nobody seems to be willing to put effort to fix the situation, it is the best to simply retire the rules.

Thanks for the detailed bug report and PR and sorry that it took so long for someone to respond.

I think we'll have to re-evaluate some badges in the future. But first we need an update, reliable backend. In the spirit of putting out fires, I will merge this for now.

Metadata Update from @gui1ty:
- Pull-request tagged with: T: bug
- Request assigned

2 years ago

Pull-Request has been merged by gui1ty

2 years ago