Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
(And leave it open!)
I think recommending a todo list formatted issue might be a good practice.Daniel Reis <firstname.lastname@example.org> schrieb am Mo., 20. Juni 2016 um 14:23:I don't really see the point. Optimistic merges are as valid and guideline enforced as all others.The only difference is that you should merge as soon as the work is good enough, even if it can still be improved.A better question is how do I now the improvements that should be added next, following the review feedback.Until now I have been asking people to write them in the README. But I get to think that it contributes to slow down the PR duration. Maybe it's best to add it to the PR top comment, or create a separate PR/Issue for that.
No dia 20/06/2016, às 08:53, Rafael Blasco <email@example.com> escreveu:
How will we know which module has been merged optimistic and which one not? Like a label or a field in OpenERP.py
ThanksEl 19/6/2016 11:38, "Daniel Reis" <firstname.lastname@example.org> escribió:
Thank you Luis,
OCA uses the simpler Feature Branch workflow, where we have a single stable branch.
The GitFlow ellaborates on this separating this reference branch into three: develop, release and master.
There is a nice comparison at the Atlassian website:
In that perspective, I can see that my initial proposal ends up being something in between, using two branches: develop and release/master.
But even that "simplified Gitflow" faces an issue:
Contributions to the OCA are mostly opportunistic.
We don't have a dedicated team, systematically working on the codebase.
Instead people share code they find that can be useful to others.
But then they need to address first their bill-paying customers, and often can't find the time or motivation to improve the code according to the review feedback.
That's the main reason why PRs are stalled - lack of follow up from the author.
So a "develop" branch would quickly become bloated with zombie code.
With Feature Branch, that code just hangs in a separate branch, and can eventually picked up by someone later.
The point with my reviewed proposal is to instead leverage collaboration on feature branches:
- have them visible (this is achieved with open PRs), and
- foster incremental collaboration in those feature branches, that today happens seldom.
For the second point, some action items could be:
- preferring breaking up feature additions into multiple PRs (instead of requesting the authors to expand the current PR).
- providing easy documentation on how to make a PR on a PR
- eventually providing some git wrapper to make it easier to fetch PR branches
Citando Luis Felipe Miléo <email@example.com>:Hi,+1There is a tool that with some adaption can even automate the process merging and creating pull requests in OCA.
https://datasift.github.io/gitflow/Available subcommands are:
init Initialize a new git repo with support for the branching model.
feature Manage your feature branches.
release Manage your release branches.
hotfix Manage your hotfix branches.
push Push the changes from your current branch (plus any new tags) back upstream.
pull Pull upstream changes down into your master, develop, and current branches.
update Pull upstream changes down into your master and develop branches.
version Shows version information.
- When a developer creates a new feature / hotfix a new branch is created on your fork. This helps other contributors know that there is someone working in a particular activity and interact with it;- When the feature is completed is made an automatic merge the branch beta (or Develop);
- When a hotfix is finished is made a merge both branch beta as the master (8.0 / 9.0);Best Regards.- Luis Felipe Miléo
Open Source Integrators, Daniel Reis