5 ms·

It’s not so much that they banned umn email, as it is they banned the university of Minnesota. This particular act is about avoiding the risk of researchers wa

It’s not so much that they banned umn email, as it is they banned the university of Minnesota. This particular act is about avoiding the risk of researchers wasting kernel developers time. As evinced by the response, it seems really unlikely that other institutions would think it’s a good idea to perform experiments on the kernel devs in the future.

x3__ 5y ago
You do know that one can contribute without having to use their institution email address ?
- tmp538394722 5y ago
  Yes, I do know that. The policy is not about them being physically prevented from emailing from not-a-umn-researcher@yahoo.com. It’s a symbolic policy, but I would be extremely surprised if a university flouted a clear and explicit ban on their participation.
nuclearnice1 5y ago
Most of the reverted commits are fine by inspection and the researched insist there were 3 hypocrite submissions that didn’t get merged. So the idea is to collectively punish the mostly innocent people who wrote the 190 good commits, spending a huge amount of developer time checking them or losing the fixes to prevent other institutions from doing this? Does reverting nearly 200 good patches seem out of proportion relative to 3 unmerged hypocrite commits?
- tmp538394722 5y ago
  That’s a fair question about proportionality. I don’t have any special insight into the kernel team, but I think the response is as much about making an example of the university as it is about removing any plausibly contaminated commits, in which case it makes sense to be somewhat extreme. Others are saying the entire research team should be fired. It’s interesting that the former (reverting the commits) is something the kernel devs can do to publish the university, while the latter (firing researchers) is something the university can do to punish the researchers. Who messed up? The researchers or the university who approved their research? Probably enough blame to go around.
  - nuclearnice1 5y ago
    Proportionality is one aspect. Punishing the right people is another. If you’re an UMN patch submitter who has just seen your work thrown away because of the actions of some researchers you don’t know and some kernel maintainer you don’t know, you’d be rightly upset. Punishing the entire university for the actions of a few. I think it’s a bad idea: https://en.m.wikipedia.org/wiki/Collective_punishment https://en.m.wikipedia.org/wiki/Collective_punishment
    - rincebrain 5y ago
      FWIW, there are no patches committed that I can find since 2013 that are not by people who are or were in the relevant lab at UMN. Maybe my research is flawed, but I don't think the bulk revert is currently hitting anyone but them. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.16&qt=author&q=umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
      - nuclearnice1 5y ago
        It’s a good observation. So for example we have a 2019 commit by Wenwen Wang being reverted. Wenwen is now at UGA. The commit is “ALSA: usx2y fix a double free bug” review by Takashi Iwai confirms it’s a good fix. I don’t agree with Greg K-H threatening to trash Wenwen’s work, his reputation, and add bugs to the Linux kernel out of spite toward researchers than Wenwen hasn’t worked with in years. Note that Aditya Pakki denies being a part of the hypocrite commits on email, maintains his denial in the apology, and has written papers on static analysis. Also, vast majority of those commits are being re-reviewed and found good. Greg Kroah-Hartman accused him of intentionally submitting bad commits. That accusation appears false. Greg should apologize to Wenwen and Aditaya. This is a broad brush. It’s hitting a bunch of good commits and we know the 3 hypocrite commits aren’t there .
        rincebrain 5y ago
        The complaints, depending on who you were listening to, were that the patches were superfluous (cf. [1], where Aditya apparently later claimed "The patch is garbage") or contained security flaws (cf. [2] for one such allegation) , whether deliberate or accidental, and that too many of them had been accepted without enough review by dint of being "trivial fixes". (One claim, for example, was "I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes"." [3], which, if false, should certainly probably provoke an apology.) Assuming [3] came from a reasonably trustworthy source after Greg's initial distrust and frustration, combined with Aditya's reply of being extremely offended that anyone would doubt his work (which, if we assume for a moment he wasn't aware of the researchers' prior work poisoning LKML's opinion of the lab, could be a reasonable reaction), it's not surprising that his conclusion was "rip out all the patches for now and re-review them as we have time". People keep overlooking that the plan was never "permanently remove the patches", it was always "remove the patches for now and then re-review them all". And now it's working as expected - people are re-reviewing the patches proposed for removal and going "hey this is fine", "hey this is harmless", or occasionally, probably "hey this is bad". (I have not read anywhere near all the replies to the thread, I'm just assuming that the people who were complaining about the patches were also operating in good faith and not just making up complaints.) I don't really see another reasonable way to have acted if you suspect a group of people has been generating and getting committed poor patches, whether out of malice or ignorance, than removing them for now and re-reviewing them. If it turns out that the patches were (probably, since I don't think there's any absolute confidence to be had here) merely bad and not malicious, then sure, an apology would be warranted for claiming malice where there was none. (And for those who don't think he ever claimed malice, like I did when I started writing this reply, see [4], specifically 'Commits from @umn.edu addresses have been found to be submitted in "bad faith" to try to test the kernel community's ability to review "known malicious" changes.') But I don't think "okay we need to re-review all these patches (and the usual thing to do if we need to re-review patches is remove them for now)" warrants an apology in itself. [1] - https://github.com/torvalds/linux/commit/799bac5512188522213e2d7eb78ca7094dfdf30c https://github.com/torvalds/linux/commit/799bac5512188522213... [2] - https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ [3] - https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/ https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/ [4] - https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

x3__ 5y ago

You do know that one can contribute without having to use their institution email address ?

tmp538394722 5y ago
Yes, I do know that. The policy is not about them being physically prevented from emailing from not-a-umn-researcher@yahoo.com. It’s a symbolic policy, but I would be extremely surprised if a university flouted a clear and explicit ban on their participation.

nuclearnice1 5y ago

Most of the reverted commits are fine by inspection and the researched insist there were 3 hypocrite submissions that didn’t get merged. So the idea is to collectively punish the mostly innocent people who wrote the 190 good commits, spending a huge amount of developer time checking them or losing the fixes to prevent other institutions from doing this? Does reverting nearly 200 good patches seem out of proportion relative to 3 unmerged hypocrite commits?

tmp538394722 5y ago
That’s a fair question about proportionality. I don’t have any special insight into the kernel team, but I think the response is as much about making an example of the university as it is about removing any plausibly contaminated commits, in which case it makes sense to be somewhat extreme. Others are saying the entire research team should be fired. It’s interesting that the former (reverting the commits) is something the kernel devs can do to publish the university, while the latter (firing researchers) is something the university can do to punish the researchers. Who messed up? The researchers or the university who approved their research? Probably enough blame to go around.
- nuclearnice1 5y ago
  Proportionality is one aspect. Punishing the right people is another. If you’re an UMN patch submitter who has just seen your work thrown away because of the actions of some researchers you don’t know and some kernel maintainer you don’t know, you’d be rightly upset. Punishing the entire university for the actions of a few. I think it’s a bad idea: https://en.m.wikipedia.org/wiki/Collective_punishment https://en.m.wikipedia.org/wiki/Collective_punishment
  - rincebrain 5y ago
    FWIW, there are no patches committed that I can find since 2013 that are not by people who are or were in the relevant lab at UMN. Maybe my research is flawed, but I don't think the bulk revert is currently hitting anyone but them. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.16&qt=author&q=umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
    - nuclearnice1 5y ago
      It’s a good observation. So for example we have a 2019 commit by Wenwen Wang being reverted. Wenwen is now at UGA. The commit is “ALSA: usx2y fix a double free bug” review by Takashi Iwai confirms it’s a good fix. I don’t agree with Greg K-H threatening to trash Wenwen’s work, his reputation, and add bugs to the Linux kernel out of spite toward researchers than Wenwen hasn’t worked with in years. Note that Aditya Pakki denies being a part of the hypocrite commits on email, maintains his denial in the apology, and has written papers on static analysis. Also, vast majority of those commits are being re-reviewed and found good. Greg Kroah-Hartman accused him of intentionally submitting bad commits. That accusation appears false. Greg should apologize to Wenwen and Aditaya. This is a broad brush. It’s hitting a bunch of good commits and we know the 3 hypocrite commits aren’t there .
      - rincebrain 5y ago
        The complaints, depending on who you were listening to, were that the patches were superfluous (cf. [1], where Aditya apparently later claimed "The patch is garbage") or contained security flaws (cf. [2] for one such allegation) , whether deliberate or accidental, and that too many of them had been accepted without enough review by dint of being "trivial fixes". (One claim, for example, was "I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes"." [3], which, if false, should certainly probably provoke an apology.) Assuming [3] came from a reasonably trustworthy source after Greg's initial distrust and frustration, combined with Aditya's reply of being extremely offended that anyone would doubt his work (which, if we assume for a moment he wasn't aware of the researchers' prior work poisoning LKML's opinion of the lab, could be a reasonable reaction), it's not surprising that his conclusion was "rip out all the patches for now and re-review them as we have time". People keep overlooking that the plan was never "permanently remove the patches", it was always "remove the patches for now and then re-review them all". And now it's working as expected - people are re-reviewing the patches proposed for removal and going "hey this is fine", "hey this is harmless", or occasionally, probably "hey this is bad". (I have not read anywhere near all the replies to the thread, I'm just assuming that the people who were complaining about the patches were also operating in good faith and not just making up complaints.) I don't really see another reasonable way to have acted if you suspect a group of people has been generating and getting committed poor patches, whether out of malice or ignorance, than removing them for now and re-reviewing them. If it turns out that the patches were (probably, since I don't think there's any absolute confidence to be had here) merely bad and not malicious, then sure, an apology would be warranted for claiming malice where there was none. (And for those who don't think he ever claimed malice, like I did when I started writing this reply, see [4], specifically 'Commits from @umn.edu addresses have been found to be submitted in "bad faith" to try to test the kernel community's ability to review "known malicious" changes.') But I don't think "okay we need to re-review all these patches (and the usual thing to do if we need to re-review patches is remove them for now)" warrants an apology in itself. [1] - https://github.com/torvalds/linux/commit/799bac5512188522213e2d7eb78ca7094dfdf30c https://github.com/torvalds/linux/commit/799bac5512188522213... [2] - https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ [3] - https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/ https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/ [4] - https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...