Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
I'm not blaming but just saying... Reviewers are doing a great job and they just have to find the good balance...
Hello,The process I would like to experiment is:
I think we should first agree on where to install from. We should move our current and new deployments from Github to use packages from http://wheelhouse.odoo-community.org.
Once the development environment is disconnected from the production ones, then we can have the approach we want on Github and try different release process and repo conf. Rolling out different ones in the same time will allow us to benchmark them, see which one works in which situation.
- Document new features and new contributions in Github issues
- Optimistic merges on 7.0, 8.0 and 9.0 branches
- Freeze branches before a release to make CI green
- Update setup directory for mature modules to trigger repackaging and tag the branch with the date ("20160606")
I would like to encourage every new and current contributors to contact the PSC on the mailing list or with a GH issue to announce their intention to work on something. Figuring out things on a PR is too late and increases the chance to get contributions refused, frustrating the contributor and the PSC member.
My 2 cents.I'm still not sure how to do it, because requires a cleaning step and many times is harder to clean.2016-06-06 10:38 GMT-05:00 Jean-Marc Dupont <firstname.lastname@example.org>:Yes, go for it !We have our first contribution waiting for approval;-)
Agence Web, e-Commerce et Systèmes d'entreprise
68, rue du Refuge - 84200 Carpentras
T. 06.24.91.02.03 - 04 84 25 17 94
Éditeur de la marque Provenc.io
1° marque e-Commerce 100% Provence
IMO, the two main goals of the new process must be:I'm guessing this will be the challenge of the next OCA board to solve and improve this situation. We should not forget that this is really a "good" problem we face, it shows that OCA has a real success !Hi all,Thanks for your feedback here. I'm still not sure how to do it, but I'm sure we need to change the way it's done currently. Too much PR left alone, too much contributors frustrated during their first contact with OCA and reviews.
* for a great contributor experience first
* to optimize maintainer time secondI also agree that some basic rules must be asked from contributors in the first place (as Ronald pointed out). But I'm convinced we can achieve this with Optimistic merging if proper tools /process are in place.Regards,JoëlHi,Thanks Daniel for bringing this to the list.My thinking goes along the following lines:- PR towards the main branch- formal releases marking stable versions- evolving towards a process that allows optimistic merging (ie Hintjens' C4 http://rfc.zeromq.org/spec:22/ or similar)This approach, as well as Daniel's, have in common to increase the burden and responsibilityon maintainers who do the releases. This is, IMHO, a necessary step, though.To make this manageable, I envision:- smaller repositories- each repo containing a very cohesive set of modules (yes that may mean some repos with only one module, I now think we can manage that)- all modules in a repo following the same release cycle- each repo with clearly identified maintainers who take full ownership on release management- such repos under the responsibility of PSC who help allocating new contributions to repositories (with the approval and endorsement of repo maintainers, of course), and ensure all maintainers respect the rules- often a new contribution will need a new repository, that is fine as long as the contributor commits to take ownership and abide by OCA rulesIt's quite a change but I think it's manageable. Perhaps with some small evolution in Q&A bots.I'm convinced smaller repositories have many advantages, mostly deriving from a clearer and stronger ownership of modules.- patches to existing modules will be reviewed sooner because owners of repos will feel more responsibility to do it sooner than later- new modules or set of modules can be accepted in their own repo provided the contributor takes ownership and agrees to maintain it according to OCA rules, the repo then lives it's own live according to classical FLOSS evolutionary laws.Food for thought...Best regards,-sbiI agree with the general idea, thanks! I have some specific remarks though. What happens often in open source is that merges are made to a mainline branch (this can be called trunk, master, develop, next...). Then maintainers make a releases with some extra review and testing. (a release is an annotated git tag, optionally with merge to a stable branch). We should then use those releases in our projects instead of git hashes as we do now. If we need a bugfix, we should try to make the effort to make a release (otherwise they are almost worthless). I think this mainline + releases strategy would be good for us as well. To avoid doubling the burden on maintainers, we do optimistic merges + releases. The merges could be (almost) automatic after a few days if the build is green and no-one blocked the PR explicitly. On the other hand I would block if unsure if that is the right branch, and in general I would try to avoid to force maintainers to cherry-pick/filter-branch at every release. This is painful, error-prone, creates conflicts etc. The goal should be that all green modules that have not been blocked should be released, eventually with a bit of extra work and review when merging. Exclusion (so filter-branch and friends) should be the exception IMO. On Mon, Jun 6, 2016 at 12:23 PM, Eric Caudal <email@example.com> wrote: > Stable branch (current one) will keep the PM strategy to keep quality > standards. > > -- > Eric Caudal [Founder and CEO] > Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 > (Office) > Elico Shanghai (Hong Kong/Shenzhen/Singapore) Odoo Gold Partner, best Odoo > Partner 2014 for APAC > On 06/06/2016 06:08 PM, Nhomar Hernandez wrote: >cite="mid:CAKtu5Y4JDZyOzGngJrWY9rtXEAWrm4yeK8JtBKjb4fiSs6KVjg@mail.gmail.com" > type="cite">We have projects where PM is mandatory and others where OM is > mandatory, can we have different strategies? > > > _______________________________________________ > Mailing-List: http://odoo-community.org/groups/contributors-15------Maxime Chambreuil
ThinkOpen Solutions Portugal, Daniel Reis