Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
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 a hotfix is finished is made a merge both branch beta as the master (8.0 / 9.0);
De: "David Arnold" <firstname.lastname@example.org>
Para: "Contributors" <email@example.com>
Enviadas: Sexta-feira, 17 de junho de 2016 20:52:57
Assunto: Re: Proposal for new workflow, incorporating "Optimistic Merging"
Can't wait! +1Daniel Reis <firstname.lastname@example.org> schrieb am Fr., 17. Juni 2016 um 17:38:
There were some relevant objections to the proposed workflow.
I took some time to work on them, and to contact Pieter Hintjens, the OM proponent, for advice about our case.
It was mentioned the OM is suitable patches, but not for new module proposals.
Pieter confirmed this. OM expects small changesets that are easier to review.
"Optimistic" just means that we should not merge them only if something clearly wrong is found.
Pieter also said that master should always build. That's the equivalent for us to always having CI green,
But or problem is exactly with larger new module PRs
AFAICT small PRs are not very frequent, and in most cases are already fast merges.
So how does Pieter's OM handle non trivial feature requests for ZeroMQ?
They create a new repo and collaborate there, until a mature enough solution is ready to merge into master.
But wait - that's the fork workflow we already use: fork the repo, develop the feature there, ask for opinions, and when ready ask for pre-merge reviews.
My conclusion is that the current workflow is appropriate, maybe we only need to foster the practice of having several people collaborating with commits in the same WIP PR.
Another suggestion that could improve PR cycle time is to block PRs only if something is wrong:
In the cases where reviewers something can be improved, made more efficient, or more complete, that should be left to a second PR, so that the original one can get merged ASAP. Similarly for some "harder to get right" features, an option might be to remove them from the original PR and having them added in a following PR.
A case that was also surfaced in the discussion was using small repos (some eventually with a single module).
This idea is not a requirement for an OM strategy, but is relevant to creating WIP workspaces where new features are matured until ready to be released as stable. Examples like Jordi's Project Earned Value Management and Elico's Business Requirements come to mind.
Until now I haven't been very sympathetic about the small repo case, since it brings coordination issues that haven't been answered yet
I gave them a lot of thought, and I believe to have found an incremental solution to the OCA workflow support for these small repos.
And this in a way that is complementary to how we work today. It is evolutionary rather than revolutionary, so we could start using it immediately, as soon as we agree on the details.
However I prefer to draft that specific proposal in a different thread.
Post to: mailto:email@example.com
ThinkOpen Solutions Portugal, Daniel Reis