5 ms·

Counterpoint: this employee wasn't trying to "bypass" anything. The change from maintainer to reviewer only means they wanted to be in copy of patches/emails in

by Aissen 6y ago

Counterpoint: this employee wasn't trying to "bypass" anything. The change from maintainer to reviewer only means they wanted to be in copy of patches/emails in order to provide feedback; providing reviewer time is basic etiquette in the linux kernel.

nolok 6y ago
You're missing that they added their personnal email in the maintainer file by using their ibm email, in the commit where they were supposed to remove themselves. Employees giving themselves personnal privileges using company resources, while being specifically asked to remove themselves from those that they had has employee, is vastly different context than "he was there as a hobby and ibm cracked down on him".
- Aissen 6y ago
  I am not missing how they changed emails, I was in fact commenting on that. Being reviewer (vs maintainer) is not having any special privilege, it's just subscribing to emails.
- miga 6y ago
  Being unpaid reviewer is not privilege that is a duty. Claiming that reviewing patches is a "privilege" is bad for the kernel, and bad for IBM.
  - drewzero1 6y ago
    I'm reading 'privilege' here in the computer user permissions sense, not the moral/duty/rights sense. Regardless, it's not a great look for anyone involved here.
- madamelic 6y ago
  >Employees giving themselves personnal privileges using company resources, They swapped from their work email to the personal email, which indicates, they won't be working on it during work time. This is an open-source project and isn't the same as adding another GitHub user to a private org or something.
  - nolok 6y ago
    And what authority did they have to add someone (themselves on personal email)? None personal. The one that they had as an employee. Would they had been added to that list using their personal email if they removed themselves THEN asked someone with the authority to do so to add them back on their personal account? Everything points to no. Ergo they misused their employees position.
    - pavon 6y ago
      The Linux kernel maintainer list isn't IBMs to grant or deny permission to. The other kernel maintainers had no objections to Lijun staying on as a reviewer, just IBM did. > Would they had been added to that list using their personal email if they removed themselves THEN asked someone with the authority to do so to add them back on their personal account? Everything points to no. What makes you say this? No commits make it into the official Linux kernel without being peer-reviewed and approved. The original change was signed off by another (non-IBM) maintainer, and would have to be signed-off again by Linus before making it into the official kernel. There have been many cases where a developer stopped working on the kernel in a professional capacity, but continued to do so in a personal capacity, and none of the Linux maintainers objected to this. Why would they? The developer has valuable experience and knowledge about the code base. I don't see any aspect of abuse of authority/privilege here, just an employee/employer contract dispute.

by Aissen 6y ago

nolok 6y ago

You're missing that they added their personnal email in the maintainer file by using their ibm email, in the commit where they were supposed to remove themselves. Employees giving themselves personnal privileges using company resources, while being specifically asked to remove themselves from those that they had has employee, is vastly different context than "he was there as a hobby and ibm cracked down on him".

Aissen 6y ago
I am not missing how they changed emails, I was in fact commenting on that. Being reviewer (vs maintainer) is not having any special privilege, it's just subscribing to emails.
miga 6y ago
Being unpaid reviewer is not privilege that is a duty. Claiming that reviewing patches is a "privilege" is bad for the kernel, and bad for IBM.
- drewzero1 6y ago
  I'm reading 'privilege' here in the computer user permissions sense, not the moral/duty/rights sense. Regardless, it's not a great look for anyone involved here.
madamelic 6y ago
>Employees giving themselves personnal privileges using company resources, They swapped from their work email to the personal email, which indicates, they won't be working on it during work time. This is an open-source project and isn't the same as adding another GitHub user to a private org or something.
- nolok 6y ago
  And what authority did they have to add someone (themselves on personal email)? None personal. The one that they had as an employee. Would they had been added to that list using their personal email if they removed themselves THEN asked someone with the authority to do so to add them back on their personal account? Everything points to no. Ergo they misused their employees position.
  - pavon 6y ago
    The Linux kernel maintainer list isn't IBMs to grant or deny permission to. The other kernel maintainers had no objections to Lijun staying on as a reviewer, just IBM did. > Would they had been added to that list using their personal email if they removed themselves THEN asked someone with the authority to do so to add them back on their personal account? Everything points to no. What makes you say this? No commits make it into the official Linux kernel without being peer-reviewed and approved. The original change was signed off by another (non-IBM) maintainer, and would have to be signed-off again by Linus before making it into the official kernel. There have been many cases where a developer stopped working on the kernel in a professional capacity, but continued to do so in a personal capacity, and none of the Linux maintainers objected to this. Why would they? The developer has valuable experience and knowledge about the code base. I don't see any aspect of abuse of authority/privilege here, just an employee/employer contract dispute.