Hi Liliana, On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler <liliana.prik...@gmail.com> wrote:
>> > > Must we force a single workflow on everyone, even if our track >> > > record in reviewing and merging doesn’t clearly show that our way >> > > is superior >> > >> > Again, define superior. >> >> No, I won’t. I think it’s obvious that our review process isn’t >> working *well*. So the argument that our current workflow allows for >> effective review is dubious. Not saying that you made that claim, >> just that it’s hard to convince others of adopting our ways when the >> results just aren’t great. > > What do you consider "the results" here? The rate at which patches are > merged? This is hardly an issue our project alone is fighting and I'm > not convinced that technology, more or less, will shift it in either > direction. That’s not about “result” here. That’s about “simple vs easy” or “complex can be easy” or etc. Similarly as submitting patches means that many steps are more or less simple, then the complete process can be considered as relatively complex. To be explicit, I do not speak about being “easy” which is subjective and instead I am speaking about some objective criteria (e.g., the number of steps even if they are trivial). Some part of that complexity has some value for the project and some other part has no value. The question is thus to identify and then remove (or hide) the complexity that has no value for the project. Today, the review and commit process have many steps, more or less simple, not all sure!, well at the end, we have something complex. One trivial step is to apply the patch (or series) to your local checkout and so many things can lead to some useless frictions. For example, the patch does not apply because the base commit is not provided, or because it is badly formatted, or because…. And one ends to fix themself, e.g., probably using some manual trick just for applying the patch. No value for the project. Yes, QA is currently helping for that specific example about applying patches but the solution depends on why the patch does not apply. Well, I am not saying that we should switch to PR model using GitHub. :-) Let just recognize that our current workflow has many drawbacks that make some frictions (steps with no value) for reviewing. And PR model à la GitHub has many other drawbacks but at least it reduces some frictions (technical steps with no value); mainly because some people are paid for removing (or hide) these useless friction. Don’t you agree that the review process implies many manual steps that have no value for the project? Last, I agree that the main issue when speaking about the reviewing process is not about tooling. The lack of a smooth technical solution is just acting as a chemical developing solution in photography, it increases the contrast and makes the poor image apparent. Cheers, simon
