GitHub user Yicong-Huang added a comment to the discussion: Merge the Python Notebook Migration Tool in a Single PR
of course, Rome is never built in a day, by merging into main branch, does not mean a feature has to work end to end. it is the releasing time that matters: features to be released are better to be functional in a desired state. The normal development loop is: 1. A few PRs to create a framework, with unit tests, mostly with a feature flag that hides the entire thing from user. 2. A few PRs to add some partial features, with unit tests 3. A few PRs to fix bugs as we develop, with unit tests 4. A few PRs to connect the new feature with other services, or hook up with frontend button etc, with integration tests. 5. A few more PRs to fix bug, add docs, refactor, polish. so far only alpha test: no users see it. 6. We decide if the feature is ready to be beta-tested, and flip the feature flag so users can see them. optionally we can flip deployment by deployment, so partial users can use the features and collect feedbacks before we include more users. 7. We include it in a release, enabling it by default, or tell users how to enable it. that's when it's done. 8. More post release bug fixes PRs .... So. my answer to this question is, when there is no time pressure, we MUST follow the above procedure to gradually review and merge small PRs. You can divide the feature vertically, or horizontally, whatever way makes sense. Or even create PRs file by file, as long as you have tests to verify the unit correctness. GitHub link: https://github.com/apache/texera/discussions/4590#discussioncomment-16776816 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
