Gerrit Contributions
-
@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.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@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.
@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.
-
@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.
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.
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 ...
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 ...
@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...
Director R&D, The Qt Company
-
@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...
@kkoehne said in Gerrit Contributions:
after the planned gerrit update...
Cool. Are there any information about the planned update?
Qt has to stay free or it will die.
-
@kkoehne said in Gerrit Contributions:
after the planned gerrit update...
Cool. Are there any information about the planned update?
-
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"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
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 -
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."La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
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.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-licenseMaybe I can get it to fully build tomorrow.
-
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 -
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 ?
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
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 ?
Will preconfiguring work, as
configuredoes compileqmake? -
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.
-
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-licenseMaybe I can get it to fully build tomorrow.
@aha_1980
What about building onlyqtbaseor 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 $> ...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
qmaketo retrigger the build, or did you mean something else? My concern is with theqmake's paths that are compiled into the binary, maybe patching them would do the trick? -
config.statusandconfig.optare all that are needed.Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Needed for? Triggering
configure? -
Re-trigger configure using the set of parameter you original passed. In the absolute,
config.optis enough asconfig.statusjust calls configure with the-redooption. -
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 .Qt has to stay free or it will die.
-
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 .@aha_1980 Thanks!
@SGaist and @kshegunov My idea was to pre-configure and even make. That's really the time saving part. The rest can literally be included in a bash file, it's not really that taxing.
@SGaist said in Gerrit Contributions:
provide a docker container
That's actually another great idea
-
As someone that has not used Docker before: it is not as cross-platform as VirtualBox, i.e. you can use a Linux docker only in a Linux environment, not Windows, right?
