Drive-by Qt contributions

Chris Kawa

So last year there was this pretty cool announcement: Code contributions via bug reports and forum posts.
At the time I was quite excited about this as I often expressed my dissatisfaction with the tediousness of the contribution process.

Since then I haven't seen any contributions through the forum. I guess it makes sense, since people rather come here to seek help, but I was wondering if any of you tried the bug reports route?
My experience with that is... well... bad, but it's been (oh so gently) pointed out to me in the past that my issues with Qt just aren't that interesting to a wider crowd, so I though I'd get a bit of an outlook.

SGaist

Hi,

Can you share a link to your contribution on the bug report ?

Chris Kawa

@SGaist Sent via chat.

Don't get me wrong - I'm not trying to lobby for my issues here. I'm more interested in knowing how the process itself works out for others.

SGaist

No worries, it was to get an idea of the contribution you were talking about.

I think that currently people are not yet used to manage this type of contribution.

aha_1980

@Chris-Kawa My opinion: if you want to integrate it - send it to Gerrit.

It's really not complicated, even if it looks like that in first place.

At the end, it's just a git remote. (and honestly, neither gitlab nor github are equivalent review tools. I already love gerrit for the functions it provides)

Regards

Chris Kawa

@aha_1980 said:

It's really not complicated, even if it looks like that in first place.

I'm guessing you're a Linux guy :)

Jokes aside, I don't want to repeat myself so here's a link to that discussion we already had: Gerrit Contributions, and just by the number of posts there you can see it's not "just a git remote" ;)

Lately I've been contributing some stuff to Microsoft's projects on github. It took me about 2 minutes and 3 clicks to set up and my changes were integrated after about half an hour. I literally went to grab a snack and it was done when I got back - bot checked, reviewed, built and released. I was shocked. First time setting up for Qt contributions on Gerrit took me days to setup, months to get reviews and ultimately those patches never got through the maze.

I'm done with that. If I have to wait months to get couple of lines in I'm gonna spend my time elsewhere. That's why I was originally very happy about the bugreports possibility - do what I do- code. Find problem, fix it and let people who know how to deal with the trenches of the system on the other side of the curtain handle integration.

aha_1980

Hi @Chris-Kawa

I'm guessing you're a Linux guy :)

Indeed. But I managed the process on Windows too.

you can see it's not "just a git remote" ;)

I understand that the setup is complicated. I've had my problems too when I started 8 years ago, but mainly because I didn't understand the process. And I had zero git knowledge at this point.

Lately I've been contributing some stuff to Microsoft's projects on github. It took me about 2 minutes and 3 clicks to set up and my changes were integrated after about half an hour.

Ok, but surely you also had to

add an ssh key to Github
clone a repository
make changes
push them go Github
wait for review
goto 3 if reviewer not satisfied
push the merge button

And that's what I mean: the Gerrit process is not completely different to that! There is a further step to sign a contributors agreement, be it.

First time setting up for Qt contributions on Gerrit took me days to setup, months to get reviews and ultimately those patches never got through the maze.

I see three problems from that.

It is hard to setup the contribution environment - we can surely improve that with good tutorials
Why did it take month to get reviews?
The patches were never integrated? What was the problem?

If I have to wait months to get couple of lines in I'm gonna spend my time elsewhere.

I know that. I have done some patches to the linux-can subsystem that never got reviewed - without letting me know why. Sending patches to a mailing list is not the right way to do reviews, IMHO, and after some weeks they are simply lost.

That's why I was originally very happy about the bugreports possibility - do what I do- code. Find problem, fix it and let people who know how to deal with the trenches of the system on the other side of the curtain handle integration

But at least you'd had to create a patch and upload it there - which would reduce the work needed for point 1. That does not guarantee that points 2 and 3 are running smoothless.

Don't get me wrong, I don't want to say everything is find, I'd like to see where the problems arive and find solutions for that.

As summary from your post the problem was 40% technical and 60% human (reviewers). Is that correct?

Regards

Chris Kawa

I've had my problems too when I started 8 years ago, but mainly because I didn't understand the process.

See, you're (unknowingly?) justifying the thing by blaming yourself. Should there really be anything to understand? It's a download/upload thing. Not that much to it if you don't look from an integration engineer perspective, which a regular contributing Joe shouldn't have to be IMO. Now he does. To fix a minor syntax error you need to be knowledgeable in dozen different, completely unrelated areas.

Ok, but surely you also had to
1.add an ssh key to Github

Nope, didn't even knew that was a thing till a lot later. Just login/pass via https like I would do with email or any website.

.. 6.

Sure, but that just describes the development process. It should be exactly those steps, but there's a lot (a lot!) more to it than that. You can't bake a cake without baking a cake, but you shouldn't have to know how to operate bakery business to do that.

push the merge button

I didn't. I asked for a pull so that someone else would take care of integrating. My work was concentrated on just that - my work, not someone else's.

And that's what I mean: the Gerrit process is not completely different to that! There is a further step to sign a contributors agreement, be it.

Sure, I do have major objections to the execution though. It should be pretty much a checkbox next or after a login step, like you accept cookies or some such.

It is hard to setup the contribution environment - we can surely improve that with good tutorials

See, no. Full stop. The process is hard so let's make it tedious too. No. How about simplifying the process so there's no need for lengthy tutorials? I mean reading through a dozen pages to do what could be done via an obvious, no instructions required, button click is no fun.

Why did it take month to get reviews?

Good question. My guess is the process is just too much about rubbing elbows with the right people. A newcomer rarely knows the right people. You kinda need social skills as much as programming ones to get anything done. Whether it's good or bad is up to your individual beliefs, but IMO the process should be agnostic to that. Honestly sometimes I just want to push a 3 line fix and get on with my work. Making friends should't have to be part of that process.

The patches were never integrated? What was the problem?

Different problems in different cases. Some examples - either change became irrelevant by the time anyone looked at it, the tests in a completely unrelated part of the system were failing and it was getting rejected or another solution was proposed to be implemented by the maintainer but never realized leaving the patch in limbo. And before you ask - pinging often just goes to /dev/null.

Number 4. Which was not on your list - I'm mainly about core and widgets modules. Nowadays Qt is all about QML, mobile and web, so getting anything fixed in a widget requires literal begging or starting a flamewar on some public channel and submitting your own fix is kinda like "-we'll call you back - but you don't have my number - that's fine".

Anyway, you got me venting frustrations, which was not my intention with this post. I often fix tiny glitches and bugs in widgets (literal one-liners, typos and such) and would just like to have a way to contribute that back in a way where it's not 0.1% development and 99.9% "the majesty of the process". I was hoping sending patches through bugreports would be it. That's why I'd like to know is it working for anyone.

From the discussion shifting to other areas bug reports unfortunately look like yet another dead channel.

aha_1980

Hi @Chris-Kawa,

I cannot fully reply to your post due to time contraints now, but to summarize we have two main problems:

technical difficulty to setup the dev and contribution environment. that should be made easier.
social difficulties to get your patches merged. I already do my best here with helping newcomers and doing reviews. I think the only way to improve things here is to have more community members taking care of the new contributors.

I was hoping sending patches through bugreports would be it. That's why I'd like to know is it working for anyone.

From the discussion shifting to other areas bug reports unfortunately look like yet another dead channel.

I'd say: Create bugreports, and if you have a fix attach it there. In the worst case (your patch is not accepted) it can still help others with the same problem (either patching locally or forcing the integration). At least for Creator I have seen a few patches from Jira that were taken.

And my personal experience is, that 30..50% of my reports were resolved, even if it took years for some of them; but the rate is not that bad. Without a report, it would be 0.

Regards

Edit:

Anyway, you got me venting frustrations, which was not my intention with this post

Keeping frustrations is also no solution ;)

JKSH

@aha_1980 said in Drive-by Qt contributions:

I'd say: Create bugreports, and if you have a fix attach it there. In the worst case (your patch is not accepted) it can still help others with the same problem (either patching locally or forcing the integration).

+1 to putting patches in bugreports. This works around the technical difficulty; I can't see it getting any simpler than this.

I'm not sure what the bugreport path will do to the social difficulties though.

Chris Kawa

@aha_1980 said in Drive-by Qt contributions:

I'd say: Create bugreports, and if you have a fix attach it there. In the worst case (your patch is not accepted)

I would be fine with patches not being accepted for one reason or another. My problem is not that. Ok, I wasn't going to point any specific issues because that's not what this is about, but for the sake of example take a look here: QTBUG-76585

2 days just to assign priority... eh, ok, maybe it was weekend or busy week, fine... but, it's been since June and the only thing that happened to that item was it changed assignee 3 times and workflow version (whatever that is). So at least 3 people looked at it.
I mean the thing is two lines, has attached example and a ready to merge patch... come on... it's not a giant multiplatform change that requires some sort of elaborate testing scheme or anything. It's practically a hello world of what a bugfix and a drive-by contribution is. There has to be a way to do this sort of thing faster.