理解并落地 DSIP 提案流程Apache DolphinScheduler 重大变更的治理指南【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler本文围绕 Apache DolphinScheduler 官方文档 DSIP 说明 展开完整讲解 DolphinScheduler Improvement ProposalDSIP改进提案的认定标准、四步执行流程、邮件讨论模板与收尾归档要求并结合仓库中的 DSIP Issue 模板、Changelog 生成脚本 与 Commit Message 规范 源码级证据说明 DSIP 是如何贯穿提案、开发、发布整条链路的。读完后你可以独立完成一次标准 DSIP 提案从判断某项变更是否属于 DSIP到创建 Issue、发送讨论邮件、拆分子任务开发直到最终归档。一、什么是 DSIP哪些变更必须走 DSIP 流程DSIPDolphinScheduler Improvement Proposal用于引入 Apache DolphinScheduler 代码库中的重大改进。它不是为小修小补设计的其目的是让社区及时知晓已经落地或即将落地的重大功能与架构变化。根据 docs/docs/en/DSIP.md以下内容应当被认定为 DSIP任何重大的新功能、重大改进、引入或删除组件任何公共接口的重大变化例如 API 端点API endpoints、Web UI 的巨大改动。文档还给出了一个兜底规则当一项变更是否属于 DSIP 存在疑问时只要有任一 committer 认为它应当算作 DSIP它就按 DSIP 处理。这一“就高不就低”的原则保证了重大变更不会被绕开社区讨论。从存储载体看DSIP 同时记录在两处GitHub Issue打上DSIP标签并在描述中附上邮件线程链接Apache 邮件列表在devdolphinscheduler.apache.org中有一个以[DISCUSS]开头的邮件线程。DSIP 按状态分为两类视图视图含义查询方式Current DSIPs当前 DSIP所有仍在进行中的 DSIPGitHub Issue 中 label 为DSIP且状态为 open 的条目Past DSIPs历史 DSIP已完成或因故终止的 DSIPGitHub Issue 中 label 为DSIP且已关闭的条目All DSIPs全部 DSIP全量 DSIP用于确定下一个递增编号按 labelDSIP过滤的全部 Issue这三个视图本质上就是同一组带DSIP标签的 Issue 在不同过滤条件下的呈现后文取编号、归档时都会用到。二、DSIP 四步流程总览官方文档把完整流程拆成四个阶段整体是Issue 先行 → 邮件定案 → 开发落地 → 邮件收尾的闭环Create GitHub Issue所有 DSIP 必须始于一个 GitHub IssueSend Discuss MailIssue 打上DSIP标签后向devdolphinscheduler.apache.org发送以[DISCUSS]开头的讨论邮件Work On It, or Create Subtask For It邮件讨论通过后开始开发小改动单个 PR 提交大改动拆子任务多 PR 提交Close After It Done所有相关 PR 合并后回复邮件线程通知社区结果Issue 关闭并从 Current 转入 Past。下面逐步展开并结合仓库中的实际文件说明每一步在工程中如何落地。三、第一步创建 GitHub Issue所有 DSIP 都必须起源于 GitHub Issue。文档给出了两种创建路径确定是 DSIP新建 Issue 时直接选择 DSIP 模板不确定是否属于 DSIP先选择 Feature request 模板提交。维护团队在评审时如果认为它应当是 DSIP会主动为 Issue 添加DSIP标签、在 Issue 中提及你并引导你来到这份文档。Issue 标题编号规范Issue 标题必须带特殊前缀[DSIP-XXX]其中XXX是 DSIP 的编号。编号是自动递增的整数你需要在 All DSIPs 视图中查看已有编号取下一个整数。仓库中的实际模板 dsip-request.yml 对此做了工程化落实模板的元信息为name: DSIP description: Suggest an idea for this project title: [DSIP-][Module Name] DSIP title labels: [ DSIP, Waiting for reply ]也就是说用该模板创建 Issue 后DSIP标签会被自动打上Waiting for reply标签则把 Issue 置入等待维护者回复的初始状态——这解释了文档中维护者会为 Issue 增加标签DSIP这一环节在工具层面是如何自动完成的。模板要求的提案内容该模板要求提案者建议用英文撰写可附中文补充说明填写以下字段字段说明Motivation为什么要做这项变更Design Detail详细设计模板提示最好提供接口设计、数据库设计等Compatibility, Deprecation, and Migration Plan若涉及兼容性、废弃或迁移需在此说明Test Plan如何测试验证这项改进Code of Conduct同意遵守项目行为准则必填勾选此外模板强制要求先在已有 DSIP 中检索勾选已搜索且未发现相似 DSIP避免重复提案。这些字段构成了后文邮件讨论与子任务拆解的事实基础。四、第二步发送讨论邮件Send Discuss MailIssue 被标记为 DSIP 之后下一步是向devdolphinscheduler.apache.org发送讨论邮件说明提案的目的与设计草案。官方给出了标准邮件模板标题格式[DISCUSS][DSIP-XXX] CHANGE-TO-YOUR-LOVELY-PROPOSAL-TITLE将XXX替换为你在第一步 GitHub Issue 中确定的编号并替换提案标题。正文模板Hi community, CHANGE-TO-YOUR-PROPOSAL-DETAIL I already add a GitHub Issue for my proposal, which you could see in CHANGE-TO-YOUR-GITHUB-ISSUE-LINK. Looking forward any feedback for this thread.注意正文中必须回链到自己的 GitHub Issue把邮件线程与 Issue 绑定起来——这正是文档要求作为 DSIPIssue 描述中需包含邮件线程链接的反向约束。讨论未通过的退路邮件线程不是单向通道社区讨论的结果有三种可能社区认为值得作为 DSIP进入第三步开发社区认为不该是 DSIP维护者终止邮件线程并移除 GitHub Issue 上的 DSIP 标签Issue 转回普通功能请求处理社区认为该变更根本不应进入 DolphinScheduler维护者除移除标签外还会直接关闭 Issue。这一分支处理机制保证了 DSIP 标签的含金量它只在社区达成共识后持续存在。五、第三步开发落地或拆分子任务当提案通过邮件线程讨论后就可以把手弄脏开始动手了。文档给出了两种提交策略单个提交可完成直接在 GitHub 上提交相关的 Pull Request提案过大、超出单次提交范畴在 GitHub Issue 中创建子任务subtasks拆分成多个提交分别提交。文档给出的实例是DSIP-1[Feature][Parent] Add Python API for DolphinScheduler该提案下挂了多个子任务和子项目。从当前仓库结构看这个 DSIP 的产出确实已落地仓库中保留了 Python API 的许可证清单 python-api-licenses佐证了 Python API 组件已进入发布交付物这也印证了 DSIP 通知社区重大功能落地 的原始目的。提交时如何标识 DSIP 来源开发阶段产出的提交如何与 DSIP 关联Commit Message 规范 定义了完整的类型表其中专门有一行[Type-ISSUE_ID][Scope] SubjectType使用场景是否必须带 Issue IDFeature用户可见的新功能是Improvement已有功能增强重构、性能、体验优化是FixBug 修复是Doc仅文档是DSIP实现某份 DSIP 提案的变更是DSIP 的 Issue IDChore构建、CI、测试脚手架、依赖升级等琐碎改动否即实现 DSIP 的代码提交应使用形如[DSIP-XXX][Module] Subject的头部XXX指向 DSIP 的 Issue ID[Module]写真实模块名如Master、Worker、API、TaskPlugin、Dao等。这一规范与 DSIP 编号体系打通后任何一次代码变更都能回溯到对应的提案 Issue 与邮件线程。六、第四步完成后关闭与归档当 DSIP 完成、所有相关 PR 全部合并后提案者需要回复自己第二步创建的邮件线程向社区通报 DSIP 的最终结果该 DSIP 的 GitHub Issue 随后被关闭并从 Current DSIPs 视图转入 Past DSIPs 视图它仍然可以在 All DSIPs 视图中被检索到供后来者查阅完整历史。这一步是整个流程中唯一回到邮件的收尾动作体现了 DSIP 对社区知情权的重视重大变更不仅要在代码上完成也要在讨论线程上闭环。七、DSIP 在发布链路中的工程证据DSIP 不只是文档约定它在仓库的发布工具链中有明确的实现。发布脚本 changelog.py 负责根据 Pull Request 列表自动生成 Changelog其中对 PR 按 label 分类且明确定义了优先级链见该文件 L27-L29 的类注释dsip feature bug improvement document chore分类逻辑在classify()方法中按此优先级逐层判断L98-L119DSIP 判定为L121-L128def _is_dsip(self, pr: Dict) - bool: Belong to dsip pull requests. return any( [ label[self.key_name].lower() self.label_dsip for label in pr[self.key_labels] ] )注意两处实现细节_is_dsip对 label 名称做了lower()比较label_dsip dsip即 PR 上无论打DSIP还是dsip都会被识别生成 Changelog 时DSIP 分区排在最前面L62-L64if self.dsips: detail f## DSIP{self.changelog_prefix}{self._convert(self.dsips)}{self.changelog_suffix} final.append(detail)也就是说带dsip标签的 PR 会在每次版本发布说明中独占置顶的 DSIP 章节与 Feature、Improvement、Bugfix 等分区并列。这与 DSIP 文档中通知社区已完成或即将完成的重大变更的目标完全一致提案阶段的社区讨论 发布阶段的置顶展示共同构成了 DolphinScheduler 重大变更的透明化机制。八、流程要点速查阶段关键动作产物/凭证认定重大新功能、组件增删、公共接口API/UI重大变化存疑时就高处理—第一步用 DSIP 模板或 Feature request 创建 Issue标题带[DSIP-XXX]前缀编号取 All DSIPs 中下一个整数带DSIP标签的 Issue第二步向devdolphinscheduler.apache.org发[DISCUSS][DSIP-XXX] 标题邮件正文回链 Issue以[DISCUSS]开头的邮件线程讨论未过维护者终止线程并摘除DSIP标签不值得合并的直接关 IssueIssue 降级或关闭第三步小改动单 PR大改动拆子任务多 PR提交信息使用[DSIP-XXX][Module]前缀相关 PR 与提交第四步全部 PR 合并后回复邮件线程Issue 关闭Current → Past归档后的历史 DSIP九、总结DSIP 是 Apache DolphinScheduler 治理重大变更的轻量提案机制它用 GitHub Issue 承载提案细节与状态流转用 Apache 邮件列表承载正式讨论与结果通报用[DSIP-XXX]编号把 Issue、邮件、提交信息、发布 Changelog 四条线索串成可追溯的闭环。结合 DSIP Issue 模板 的自动标签、Commit Message 规范 的DSIP类型、Changelog 生成器 的dsip最高优先级可以看出 DSIP 在工程层面被完整落实。对于贡献者而言判断标准很清晰凡是引入/删除组件、重大新功能、公共接口API 端点、Web UI大改就按本文四步流程走 DSIP而对于读者与维护者DSIP 视图Current/Past/All也是追踪 DolphinScheduler 架构演进最可靠的第一手索引。中文读者可对照参考 中文 DSIP 文档。【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考