CI system maintainability

Alexander Neundorf neundorf at kde.org
Thu Mar 28 20:53:06 GMT 2019


Hi,

On 2019 M03 28, Thu 16:04:01 CET Boudhayan Gupta wrote:
> Hi,
> 
> On Thu, 28 Mar 2019 at 15:21, Kevin Ottens <ervin at kde.org> wrote:
> > Hello,
> > 
> > On Thursday, 28 March 2019 14:33:59 CET laurent Montel wrote:
> > > I am against to force mandatory review, as it will create a lot of lose
> > 
> > of
> > 
> > > time,
> > 
> > As I said, unpopular.
> 
> I don't get why mandatory code reviews are so unpopular.
> 
> I don't care if you lose time. 

Oh, yes, you do.
Assuming a developers would severly loose time due to waiting for reviews, at 
some point motivation would decline, at some point contributions and progress 
would decline...

> I don't want the guys building my house to
> cut corners mixing my concrete because it's going to save time. 

I would certainly be happy enough if an experienced guy would build my house 
in a reasonable time relatively quickly, more happy than if he would have to 
wait for some authority to check hs work after every day, and so make almost 
no progress anymore...
(I'm not saying that mandatory reviews would have that effect, I just think 
the argument is wrong).

> Why are you
> in such a massive hurry to make changes to software which for example holds
> access to my Google Account password? In fact, the very fact that you make
> this argument makes me wonder if I'm running trustable code on my computer
> at all, 

Now, when you raise the question whether kmail+akonadi is "trustable code", 
the ice is getting thin...
I think not having mandatory code reviews for akonadi + kde pim is not the 
problem in the case of kdepim.

...
> As a user, I simply do not want unreviewed crap running on my computer.
> Yes, crap, because no software engineer writes bug-free code all the time,
> and if you're so overconfident that you don't need reviews on even your
> one-liners, you're probably too overconfident to be writing good code
> anyway, so I'm going to operate on the presumption that if the code hasn't
> had more than one pair of eyeballs ever looking at it, it's crap.

If you put it that strong, it's wrong.
Code which has not been reviewed is not generally "crap". Code which has been 
reviewed is not generally "high quality".
Unreviewed code can be good, and often is good, and reviews, maybe especially 
if they are mandatory, *can* be crappy: just pointing out formatting issues, 
Oking the patch without understanding the big picture (and feeling somewhat 
pressured to accept a patch because the review is mandatory and otherwise you 
are blocking the other developer, etc.)

> As a developer, I know that even one-liners, and especially one-liners, the
> sort where you think "meh, this is a tiny little thing, I don't have to be
> careful" are the ones that have the most dangerous typos and unintended
> bugs.

That's also a wrong argument. one-liners are not especially prone to causing 
most bugs. They may introduce bugs, but I think, since they are small, this is 
less likely than for bigger patches.

...
> In a project like PIM, if the code hasn't been through review, which
> independent party do I trust to verify that you're not, for example,
> leaking my Google password to some world-readable tempfile? 

Having mandatory reviews for a central and complex component like akonadi 
looks like a very good and obvious idea.
OTOH if there is only one developer who is really expert for akonadi, this 
makes it kind of unfeasible.
IMO this specific case is also a technical issue. Akonadi makes things 
complicated (and it's already 13 years old, so it should be mature in the 
meantime).

...
> Let me be very clear - even if you're the best damn programmer on the
> planet, if *you* wrote the code, I do not trust *you* one inch to tell me
> that that code is correct. That verification needs to come from someone
> else, someone who does not have a conflict of interest in seeing that code
> get into production.

Sorry, your arguments are too black & white.

Alex






More information about the kde-pim mailing list