-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add rfc for exit packages #4
Conversation
1f1ac89
to
a6b2380
Compare
rfcs/0003-exit-packages.md
Outdated
|
||
我们需要完善软件源中包退出的流程,以便及时发现软件包的退出,并及时通知用户。现有流程:https://wiki.deepin.org/zh/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E7%AE%A1%E7%90%86 | ||
|
||
## 详细设计/制度正文 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
包的依赖关系要如何处理,remove一个包时被通过后,依赖这个包的其它包都自动移除?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
有依赖这个包的其他包,那么这个包的 remove 就不应该通过,直到通过流程 remove 了所有依赖它的包
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
是的,我的想法是如果存在其他的包 那应该在ci扫描出来之后挂起这个pr 直到不存在其他依赖的包
情况 2:如果软件包存在同名替换方案,在 pr 被提出且在 7 天内无反对意见后,将软件包替换为同名替换方案(CI 源),并交由测试人员进行测试。(将测试流程 pr 关联至此 pr) | ||
在节点时间后将软件包更换为同名替换方案(软件源)并将软件包退出的信息添加到 removed-packages.yaml 中,关闭 pr。 | ||
|
||
情况 3:如果软件包存在非同名替换方案,原软件包停止维护,此情况无需立即移除软件包,可使两种软件包共存一段时间,以便用户进行迁移。在原方案出现漏洞或问题时,参照情况 1 进行处理。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
情况3,两种软件包共存一段时间具体是多久?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
具体未确定时间,而是等待原软件包出现问题后,才将原软件包移除
软件包不在维护有2种情况, 一种是这个项目作者不在维护, 一个是这个项目的仓库存在多个版本,低版本不再维护。后者RFC里没有涉及, 如何处理? eg:python2, kernel 4.x以下的版本, boost,qt4等类似组件包. 而且这些包移除对社区生态会有影响 |
|
推荐用 distrobox 使用 deepin 20 来运行这些旧版软件,23 不应该提供这些旧版本软件了 |
提醒参与讨论的各位:如果上述评注中的讨论均已解决,请别忘记点击 Resolve conversation。若所有已知问题均已解决,别忘了联系主推此 RFC 的 TC 成员发送邮件,用以声明此 RFC 的定稿并进入最终评审阶段 :) |
如果是库呢? distrobox并不是一个非常完美的方案. 应该作为完全没办法用其他方式跑起来的情况下的兜底方案来用. |
看其是否存在漏洞并且设置一个退出时间,和其他主流发行版保持一致即可 |
具体是多久呢. 以及我突然想问一下, 主流发行版的包退出机制是什么样的? 我突然产生了搞这么复杂不如直接靠TC投票表决是否退出的感觉. |
这里面似乎并没有当前这个pr关心的部分? 我的意思是这个文章里没有说他们是如何讨论并决定应该移除python2的. 如果我看漏了请指正. |
我的意见是:如果可行的话 新建一个页面追踪一个影响较大的包进行退出流程,比如qt4 python2,因为大多数此类包低版本的停止维护后,依赖其开发的软件都会切换至高版本进行开发,少数无人维护的包就走无人维护的包退出流程。当我们/(TC)认为退出对于生态的影响可控的时候,则退出此类包,并可以使用类似DCM的方式作为兜底 |
rfcs/0001-exit-packages.md
Outdated
情况2:如果软件包存在同名替换方案,在pr被提出且无反对意见后,将软件包替换为同名替换方案(CI源),并交由测试人员进行测试。(将测试流程pr关联至此pr) | ||
在节点时间后将软件包更换为同名替换方案(软件源)并将软件包退出的信息添加到exit-packages.yaml中,关闭pr。 | ||
|
||
情况3:如果软件包出现严重CVE漏洞,需要立即移除软件包,需要在pr标题中引用CVE漏洞编号,由deepin-sysdev组进行投票处理,投票通过后,将软件包移除,并将软件包退出的信息添加到exit-packages.yaml中。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
软件包移除由sysdev组执行
rfcs/0003-exit-packages.md
Outdated
情况2:如果软件包存在同名替换方案,在pr被提出且无反对意见后,将软件包替换为同名替换方案(CI源),并交由测试人员进行测试。(将测试流程pr关联至此pr) | ||
在节点时间后将软件包更换为同名替换方案(软件源)并将软件包退出的信息添加到exit-packages.yaml中,关闭pr。 | ||
|
||
情况3:如果软件包出现严重CVE漏洞,需要立即移除软件包,需要在pr标题中引用CVE漏洞编号,由deepin-sysdev组进行投票处理,投票通过后,将软件包移除,并将软件包退出的信息添加到exit-packages.yaml中。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这种情况需要讨论,立即移除是不可取的,除非各大社区都一致移除该软件包
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: BLumia, zccrs, Zeno-sole The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
记录:
|
Log: