Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
> I just talked to one of the contributors of OpenUpgrade, and we agreed this repo might be a good testbed
I agree that optimistic merging is a good fit for OpenUpgrade.
The tests + merge on green sounds like a good strategy, and it can be implemented regardless of whatever comes out of this discussion.
I can't find much to add, other than mentioning the project's specific merge criteria somewhere in the docs.
While it is certainly an interesting experiment, I'm afraid it won't be able to provide evidence about many of the concerns presented for "regular" repos.
Citando Holger Brunn <firstname.lastname@example.org>:> The goal would be for a few volunteers to drive an *experiment* with > optimistic merging, in a couple of selected repos. It should keep having > stable versions with peer reviews and mandatory passing tests. Quality of > published modules must not be compromised in the process. I just talked to one of the contributors of OpenUpgrade, and we agreed this repo might be a good testbed: Here, it's in the nature of the topic that a contribution only covers some specific cases (you often only migrate the parts of a module you actually use), there are outrageous times for PRs to get merged because we're way too few people, and things are not helped by the fact that you need in-depth knowledge of Odoo n, Odoo n+1, the code of both versions, and a deep functional understanding of the domain to say something useful about the code in question. So what we talked about was: - introduce rigid tests - everything that doesn't fail the tests can me merged more or less at once This will help us with the for this repo quite notorious problem that the migration scripts for module X are partially done, but given there's a pending PR for months, other people are discouraged from adding fixes because it clumsy to PR on the PR's branch. Would the proponents of optimistic merging maybe be willing to write out their exact vision on https://github.com/OCA/OpenUpgrade/issues ? I plan to start with the testing part in the coming days (we need that independently of using this approach or any other). Another beauty of this repo is that there's no real issue of deployment here. It seems to me that many people in this thread tie the question of the merge process to the process of deployment, which complicates stuff unnecessarily in my opinion, because they are pretty much disparate topics. PS: I still think for most repos this is not the solution. In my opinion, the solution is rather some kind of karma/kudo system where you need to have done reviews before your stuff is reviewed and subsequently merged. Sounds simple, but I fear it's hard to come up with a measurement of what a 'sensible review' is. That put aside, it would make reviewing part of the submitting process, and this way give us a lot more reviewers. And as soon as you've done a few reviews, you'll notice how much you learn from it and do it anyways afterwards. If you want to talk about this, please start a new thread in order not to hijack this one. -- Therp - Maatwerk in open ontwikkeling Holger Brunn - Ontwerp en implementatie mail: email@example.com web: http://therp.nl
Open Source Integrators, Daniel Reis