Gerrit Contributions

SGaist · 11 Jul 2018, 07:51

@kshegunov said in Gerrit Contributions:

@SGaist said in Gerrit Contributions:

Threads on the forum tends to disappear over time and the patches would be really hard to associate with any given bug/problem.

This can be fixed by introducing a couple of special rules, so I don't see it as a big problem.

Any example in mind ?

Furthermore, this would pose other problems like having people posting patches that might solve something but break something else.

Happens all the time in gerrit too. This isn't a valid argument in my mind.

I didn't write my thoughts well. My concern is rather that there will be unexperienced people finding these patches (I know it goes against my suggestion that threads get lost in times), apply them and possibly trigger new bugs that will make their life way harder than it should be.
The patches in gerrit are reviewed and updated until they stop breaking the build and the ones provided in Jira will have more contextual information.

Also, the forum is not monitored therefore it's going to be even more complicated.

This would be the biggest problem as I see it. We've been running our own show more or less, Tero being lenient and all. And such "casual" contributions will still need to go through one of QtC's developers (as mentioned in the blog post). It ain't gonna be easy, that's for sure. Also @kkoehne might have something to say for or against here ...

Tero trusted us because we proved our worthiness. For the casual contributions, that's the point: having a simpler way to provide small patch is really nice, but multiplication of the channels where you can provide patches will likely make things more complicated for development. For patches posted on the forum, we will need people to monitor them (maybe a new group of dedicated persons) and ensure that they are properly posted, with enough information. Then the last point is to have someone taking the responsibility of making a submission out of it and continue the process until integration.

Indeed @kkoehne's input will be nice.

What would be nice is to have tools that help casual contributors to setup their environment to submit their patches. Since they would have already built Qt for their patch, it would really mean just setting up for Gerrit.

This would be very, very nice. The perfect solution, but are you volunteering? I, for one, don't know the infrastructure well enough to even consider helping with such a task ...

I have some ideas about that but I don't know yet about the implementation.

VRonin · 7 Nov 2018, 08:00

@SGaist said in Gerrit Contributions:

but multiplication of the channels where you can provide patches will likely make things more complicated for development.

No, I think this is the crucial point, we would keep gerrit as the only development tool.
Take my example:
I opened a bug report ticket
I'm pretty sure I would be able to solve it.
The git configs are too invasive for me to apply to the environment I use everyday and building a VM just for that would be close to madness.
My only option at the moment is to hope some poor sod that (1) doesn't have my restrictions (2) comes across the same issue and (3) can solve it (this combo probably gives me the same chances as winning lotto) comes along and picks it up.

Having a forum channel would let me post the 1-method-patch here so that if somebody with a gerrit setup and a few minutes to spare can post it; basically removing 2 and 3 above from the "list of things that need to happen". If the gerrit review fails and the original poster doesn't update it then it's just another dead commit, it's not the first and it will not be the last

SGaist · 11 Jul 2018, 09:01

@VRonin Since you have the ticket, why not post the patch to the ticket directly ? Posting it in a thread here, then posting a link to the forum that contains the patch on that ticket is a bit counter productive as you'd have the information spread in different places when one would be enough. And don't forget the classic formatting trouble that will happen here when grabbing the patch.

Don't get me wrong, I do understand the appeal of having such a channel, I'm not totally against it. However, as already written, I would rather have a tool that allows casual contributors to submit patches more easily to somewhere already monitored and properly managed for somebody to pick and continue.

If possible, a tool that would allow them to setup gerrit and git. On the git note, I agree that the proposed way of setting up git is a bit intrusive, however you can make all these settings local to your Qt repositories.

kshegunov · 7 Nov 2018, 09:02

@SGaist said in Gerrit Contributions:

@kshegunov said in Gerrit Contributions:

@SGaist said in Gerrit Contributions:

Threads on the forum tends to disappear over time and the patches would be really hard to associate with any given bug/problem.

This can be fixed by introducing a couple of special rules, so I don't see it as a big problem.

Any example in mind ?

A set of rules how would a drive-by contribution look like and what information it should contain. That'd include the link and ticket number, formatted code - with tags and appropriate code style and perhaps a requirement for a test case. I agree that it'd be better to do this in JIRA, simply as it allows also code to be uploaded directly, not just pasted inside the text as here. Still I do agree that a person should be assigned to at least monitor the hypothetical subforum and to make sure posts there are compliant.

My concern is rather that there will be unexperienced people finding these patches (I know it goes against my suggestion that threads get lost in times), apply them and possibly trigger new bugs that will make their life way harder than it should be.

You mean directly? That's crazy! ;)
Joke aside a big fat disclaimer should deal with that problem - the code is experimental and for Qt's own use, do not apply in your code base - or something along those lines.

Tero trusted us because we proved our worthiness.

You may have, but I did no such thing! ;P

I have some ideas about that but I don't know yet about the implementation.

You should open a thread and lay it out for us, maybe an idea will sprout out of it.

however you can make all these settings local to your Qt repositories.

This is what I do. Global configs are evil.

kkoehne · 17 Jul 2018, 11:28

@kshegunov said in Gerrit Contributions:

Also, the forum is not monitored therefore it's going to be even more complicated.

This would be the biggest problem as I see it. We've been running our own show more or less, Tero being lenient and all. And such "casual" contributions will still need to go through one of QtC's developers (as mentioned in the blog post). It ain't gonna be easy, that's for sure. Also @kkoehne might have something to say for or against here ...

Let me just say that the legal side has been eased a bit. We can accept patches in forums and bug reports now:

https://blog.qt.io/blog/2018/05/16/code-contributions-via-bug-reports-forum-posts/

I'd recommend sticking to bugreports.qt.io for patches though, not setting up anything in particular in forums. Both other users and reviewers are much more likely to find the patch alongside the bug or feature it fixes, in the bug tracker.

And yes, we should also ease the steps people have to do to contribute via gerrit. I do hope we revisit this soon, after the planned gerrit update...

aha_1980 · 17 Jul 2018, 11:31

@kkoehne said in Gerrit Contributions:

after the planned gerrit update...

Cool. Are there any information about the planned update?

kkoehne · wrote on 17 Jul 2018, 11:31

@aha_1980 , just that this is very high on the priority list after summer vacation period.

VRonin · 30 Jul 2018, 07:39

Just an idea to facilitate one-off code submission.
I could prepare a Virtual Box image with a system with all the plumbing in place to contribute to Qt including a small gui to facilitate non pre-configurable actions (like setting up username and password). This should cut down dramatically the time from idea to code.
Thoughts? If you think it's a bad idea say it, I won't be offended

aha_1980 · V VRonin 30 Jul 2018, 07:28

@VRonin

That actually sounds great! A Linux system should be save from license side.

And if the Qt is already configured and build, you'll save the compile time too :)

VRonin · 30 Jul 2018, 15:57

I was thinking just a straightforward debian build.
Anyone has a full post-compile qt5.git repo? I just want to know how big the whole package would be.

aha_1980 · 30 Jul 2018, 20:50

@VRonin

I just tried to do a full build, but my system stopped "out of memory" in Qt3D.

Disk used so far: 23 GB.

I didn't even include the QtWeb* modules, see below.

perl init-repository --module-subset=default,-qtwebkit,-qtwebkit-examples,-qtwebengine
./configure -developer-build -opensource -nomake examples -nomake tests -confirm-license

Maybe I can get it to fully build tomorrow.

mrjj · V VRonin 30 Jul 2018, 07:28

@VRonin
That would an epic good idea.
We use this method exclusive at work and sit a huge timer saver.

SGaist · 30 Jul 2018, 20:30

What about having it pre-configured and people can start compiling it after they did the modifications they want ?

Another possibility could be to provide a docker container ?

kshegunov · S SGaist 30 Jul 2018, 19:13

Will preconfiguring work, as configure does compile qmake?

SGaist · wrote on 30 Jul 2018, 20:34

Good point, what could be done is to pre-configure Qt, clean everything and just keep the configuration files needed to re-trigger Qt's build.

kshegunov · wrote on 30 Jul 2018, 20:50

@aha_1980
What about building only qtbase or the essential set of modules? That should be more manageable, even if somewhat constraining?
Something like the following configuration:

$> perl init-repository --module-subset=essential
$> ./configure -developer-build -opensource -nomake examples -nomake tests -confirm-license
$> make module-qtbase
$> make module-qtquickcontrols2
$> ...

@SGaist

Good point, what could be done is to pre-configure Qt, clean everything and just keep the configuration files needed to re-trigger Qt's build.

Ehm, you do need qmake to retrigger the build, or did you mean something else? My concern is with the qmake's paths that are compiled into the binary, maybe patching them would do the trick?

SGaist · 30 Jul 2018, 21:32

config.status and config.opt are all that are needed.

kshegunov · S SGaist 30 Jul 2018, 20:55

Needed for? Triggering configure?

SGaist · wrote on 30 Jul 2018, 21:53

Re-trigger configure using the set of parameter you original passed. In the absolute, config.opt is enough as config.status just calls configure with the -redo option.

aha_1980 · 31 Jul 2018, 07:10

Full build finished with make -j 1 ;)

Following sizes include the .git repos, the sources and the developer (debug) build artefacts, as said exluding QtWeb*:

961M	./qtxmlpatterns
9,0M	./qtspeech
58M	./qtgraphicaleffects
5,2M	./config.tests
2,1M	./coin
4,0K	./qtquick1
266M	./qtsensors
4,0K	./qtdocgallery
168M	./qtnetworkauth
1,5M	./qtmacextras
4,0K	./qtfeedback
496M	./qtdatavis3d
80M	./qtremoteobjects
18M	./qtgamepad
1,9G	./qttools
41M	./qtimageformats
149M	./qtvirtualkeyboard
1,6M	./qtandroidextras
116M	./qtqa
488M	./qtcharts
201M	./qtwebview
859M	./qtquickcontrols2
51M	./qtdoc
3,3G	./qt3d
4,0K	./qtwebengine
2,3G	./qtdeclarative
5,9M	./.git
1,4M	./qtrepotools
12M	./qtserialport
27M	./qttranslations
1,8G	./qtlocation
659M	./qtscript
174M	./qtwebsockets
160M	./qtquickcontrols
13M	./qtwayland
904M	./qtmultimedia
7,9G	./qtbase
70M	./qtscxml
202M	./qtserialbus
4,7M	./qtwinextras
4,7M	./gnuwin32
441M	./qtconnectivity
125M	./qtcanvas3d
21M	./qtwebglplugin
162M	./qtwebchannel
151M	./qtpurchasing
254M	./qtsvg
3,8M	./qtx11extras
4,0K	./qtpim
4,0K	./qtenginio
4,4M	./qtactiveqt
4,0K	./qtsystems
25G	.