倍可親

明大LINUX事件的反思(8): 皆大歡喜好結局

作者:oneweek  於 2021-5-6 02:31 發表於 最熱鬧的華人社交網路--貝殼村

通用分類:熱點雜談

Linux基金會發布了從頭至尾的報告 https://lwn.net/ml/linux-kernel/202105051005.49BFABCE@keescook/

This report summarizes the events that led to this point, reviews the "Hypocrite Commits" paper that had been submitted for publication, and reviews all known prior kernel commits from UMN paper authors that had been accepted into our source repository. It concludes with a few suggestions about how the community, with UMN included, can move forward.本報告總結了到此時的所有時間, 審查了明大「假裝好意提交」的文章,和其作者以前提交的補丁。本報告提出幾個建議以便社區包括明大可以向前看
Moving forward  


The Linux kernel was started by a university student, and there have been strong ties between the kernel and academic communities ever since. This collaboration is beneficial both to Linux, which gains from the work and ideas of researchers, and to the research community, which is able to work with a heavily used kernel and see its ideas deployed in practice. This collaboration is worth preserving -- and, indeed deepening.  The incident described in this paper is seen by some developers in both camps as a threat to that collaboration, but it need not turn out that way.

We have two specific recommendations designed to ensure that the kernel project and UMN can continue to work together successfully in the future:   
- UMN must improve the quality of the changes that are proposed for    inclusion into the kernel, and   
- The TAB, working with researchers, will create a document explaining   best practices for all research groups to follow when working with the    kernel (and open-source projects in general).  

The combination of these two changes, we hope, will help the kernel and research communities to work together fruitfully and prevent incidents like this from occurring again.

Development process changes  

In the past, the kernel community has often had to deal with a pattern of low-quality patches originating from a single company or group. These patches consume scarce maintainer time and, over time, lead to tense relations between the two groups.  In such cases, the kernel community has worked with the companies involved to set up internal procedures to make the patch creation and submission process work better.  When set up properly, such a process can reduce the mentoring load on kernel maintainers and enable contributors to be more successful in their work.  

A common practice in many companies is to designate a set of experienced internal developers to review and provide feedback on proposed kernel changes before those changes are submitted publicly.  This review catches obvious mistakes and relieves the community of the need to repeatedly remind developers of elementary practices like adherence to coding standards and thorough testing of patches.  It results in a higher-quality patch stream that will encounter fewer problems in the kernel community.  

We believe that UMN could benefit from a review process of this type, and recommend that UMN find at least one experienced developer to fill this role.  Having such a reviewer in place could have prevented the submission of many of the flawed patches described here.  Working with an experienced developer can also help UMN researchers toward better interactions with the kernel community and would, hopefully, prevent concepts like the "Hypocrite Commits" project from getting beyond the idea stage. 

Until such a review process is put into place, it will be difficult to re-establish the trust between UMN and the kernel community, and patches from UMN will continue to find a chilly reception.  If UMN needs help to find such a developer or to set up an internal review process, the TAB will be glad to assist.  This is a role the TAB has played with many groups in the past.



高興

感動

同情

搞笑

難過

拍磚

支持
1

鮮花

剛表態過的朋友 (1 人)

評論 (0 個評論)

facelist doodle 塗鴉板

您需要登錄后才可以評論 登錄 | 註冊

關於本站 | 隱私權政策 | 免責條款 | 版權聲明 | 聯絡我們

Copyright © 2001-2013 海外華人中文門戶:倍可親 (http://big5.backchina.com) All Rights Reserved.

程序系統基於 Discuz! X3.1 商業版 優化 Discuz! © 2001-2013 Comsenz Inc.

本站時間採用京港台時間 GMT+8, 2024-3-28 21:37

返回頂部