Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
Now I think the OCA sometimes fails to define its borders and try to embrace the world. IMHO this is doomed to fail. Open source ecosystems do have its economics behind. Until recently Odoo wasn't very stable nor full featured enough to be appealing to governments or large companies (unlike Linux, openoffice etc..). And unlike some web toy, It was also too complex for occasional users to contribute good stuff. That means it was mostly pushed by specialized integrator companies who derive their revenues from being specific project leaders and getting marketing visibility with it. That's a classical pattern. These integrators can agree on many things, but there is no money flowing in that market yet to afford making them agree on everything. And I think this is fine. Like the Rails ecosystem has a strongly reviewed core of 4-5 gems, the rest of the scope is very active, very professional and very attractive without any official review bureaucratie.
So again, I advise having several rings of compliance in the OCA with possible incubator styles repo for stuff far from that common core.
Hi David, that's off topic for this discussion.
For what is worth, we want code style conformity.
If you do it by hand or use some code formatting tool, it's up to you.
Personally, I'm not fond of automatic formatting,
For example, IMO difficulties with line lengths are usually a symptom
that some refactoring is needed, such as isolating pieces of logic
inside a function, or using variables as aliases to longer expressions.
Citando David Arnold <firstname.lastname@example.org>:Hi Danielas part of endless discussions and time consuming and discouraging ping-ping (and to many just a waste of time) is code style, you should have a look at this tool, I already proposed some time ago:https://github.com/google/yapf - It came to end code formatting pedantism..Best, DavidDaniel, I thank you for the initiative. You definitely are speaking out of my heart when you reveal the problems! I really like your proposal. To me, Bidoul's analysis incorporating Maxime's feedback about the wheelhouse, was the most complementary one: Having more distributed responsibility in smaller units is a definite win! There is a common wisdom in management cybernetics: "you need to meet chaos with chaos, if you want to succeed"! I also want to highlite what Jairo said about the labeling and it's psychological effects of feeling "welcome" and it's very positive effects for self-education.From what I was reading, the following triad might satisfy all relevant concerns:- Easy Onboarding: Quicker and less restrictive merge, encourage first basic Self-QualityAssurance by the proposed labeling approach.- Distribute Maintenance Burden: Smaller Units of Responsibility- Quality: Release Workflows (aka Tags and wheelhouse builds - focus on reducing burden by improving tooling)Best Regards, and I really haven't enough thumps to put up for this initiative!
> 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 <email@example.com>:> 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: firstname.lastname@example.org web: http://therp.nl
Open Source Integrators, Daniel Reis