CI system maintainability

[Kevin Ottens]

Hello,

On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote:
> On 2019 M03 28, Thu 16:04:01 CET Boudhayan Gupta wrote:
> > 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.)

Hell yeah, it's not a silver bullet. Actually it can be only one safety net 
among others. None of them are perfect, none of them will catch it all or be 
of good quality all the time, it's just about mitigating risks as much as 
possible.
 
> > 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.

I don't think that's true. It's a question of complexity in the system really. 
In a trivial system indeed they are less likely to introduce bugs than for 
bigger patches... but as the software grows and complexity rises (especially 
with the multiplication of mutable states) one liners tend to be as error-
prone as 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.

Yep.

> OTOH if there is only one developer who is really expert for akonadi, this
> makes it kind of unfeasible.

That's the chicken and egg problem we're in concerning KDEPIM. The developer 
story is frankly really harder than most software out there which makes it 
unlikely for people to pick it over something else for contributions. That's 
in part tied to your next point below and partly tied to documentation, on-
boarding etc. The unwillingness to be slowed down is getting in the way of 
fixing that situation: to be a desirable project to contribute to you need to 
spend time advocating, documenting and taking newbies by the hand until they 
become regular contributors.

Yes it's tough, and TBH I'm guilty of not doing this more on my own projects. 
But on such a strategic piece of software like KDEPIM there's some 
responsibility in carrying those duties for the well being of the project.

> 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).

Yes, it's byzantine really. And the user experience is still not great (to be 
polite), had to setup some new hardware recently and I was honestly almost to 
the point of throwing it all through the window.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190329/5489f316/attachment.sig>