Gerrit Contributions


  • Qt Champions 2017

    @tekojo said

    Pushing stuff into gerrit is pretty complicated. I wish we would allow "drive-by-contributions" through github or some other simple channel. That would remove / simplify these cases.

    I believe this question was raised in the mailing list, unfortunately I can't find the thread currently. However as far as I had understood then it had been "redirected" to the developer's mailing list, so perhaps you could do a very fast inquiry how and if it progressed? I'd certainly be interested to know.

    One of the proposed solutions, if I remember correctly, was to allow uploading the relevant code somewhere and then a person that knows how to go through the motions gerrit-wise may pick it up and submit it as a proper patch. This could work for occasional contributors like myself - taking someone else's code refactoring it a bit if necessary to comply with Qt's codestyle, maybe writing a unit test and finally pushing it all to gerrit for review.


  • Moderators

    @kshegunov said

    One of the proposed solutions, if I remember correctly, was to allow uploading the relevant code somewhere and then a person that knows how to go through the motions gerrit-wise may pick it up and submit it as a proper patch. This could work for occasional contributors like myself - taking someone else's code refactoring it a bit if necessary to comply with Qt's codestyle, maybe writing a unit test and finally pushing it all to gerrit for review.

    The main thing we need is a way for the code's author to formally agree to the Qt Project's Contributor License Agreement. This is currently done through Gerrit.

    If there's a way for the author to sign the agreement and then upload code without learning Git/Gerrit, that might lower the barrier for newcomers (although we'd then also need a way to then track if this "casual" upload has been picked up by someone and submitted to Gerrit)


  • Lifetime Qt Champion

    The CLA agreement logic could potentially be added to the Qt Account however I don't know how much work it can represent to integrate that with Gerrit but it could be a more friendly page for newcomers.

    AFAIK, there's no "upload a diff" concept in Gerrit so setting up git properly is not optional. At the extreme end we could potentially provide some sort of setup script/tool maybe through Qt Creator to make things easier.

    Note that the current initialiser script to get a working Qt5 git clone already provides all the options to setup Gerrit and the related hooks to get a nice working environment to hack on Qt.

    What is left to the user to do by hand is:

    • Accept the CLA
    • Create the SSH keys
    • Upload them to Gerrit
    • Hack and Push

    Note that there's the qtrepotools module that might offer some nice helpers to use in the Qt Gerrit workflow. Adding them to the documentation might also help lower the entry barrier.


  • Qt Champions 2017

    @JKSH said:

    The main thing we need is a way for the code's author to formally agree to the Qt Project's Contributor License Agreement. This is currently done through Gerrit.

    I think the point was that the original submitter only agrees to "free" the code from any copy rights. So that makes the person submitting it as a patch (e.g. me, or you) to do it from within the framework of his own signed CLA.

    @SGaist said:

    Note that the current initialiser script to get a working Qt5 git clone already provides all the options to setup Gerrit and the related hooks to get a nice working environment to hack on Qt.

    The point is however that many (speculating on how "many" here) people choose not to bother for one reason or another. They have a solution that patches up their code but decide it's too much hassle to submit it. My father has such a piece of code for fixing some drag-n-drop bug in the list/table view. I've been trying to make him submit it ... unsuccessfully ...


  • Lifetime Qt Champion

    Should we try to create a script that does the basic command line stuff leaving essentially the CLA and ssh key upload up to the user ?

    The ssh key handling part being a bit tricky...

    Tell him I'd be happy to review that although I can't give a +2 ;)



  • @kshegunov said in Gerrit Contributions:

    They have a solution that patches up their code but decide it's too much hassle to submit it.

    Yes, I think this is a major disadvantage for people (like me) that can work out a solution for a minor bug but that consider the set-up of the environment too costly (in terms of time and attention) to care. This might lead to Qt devs to focus on major bugs and new features while, quite naturally, minor bugs (priority 3 or worse) remain hanging. At least a minority of those would normally be fixed by the community, as it shouldn't require a huge programming effort, but the process discourages it. KDE in my opinion does a much better job in this sense (https://phabricator.kde.org/). I realise, however, that the main limitation here is the license.


  • Moderators

    I have to agree that this tedious process is a blocker for many potentially valuable contributions.

    Out of my own experience - the first time I tried to set up gerrit (was a few years back) I gave up because the process was very Linux-centric and I just couldn't be bothered to work out all the quirks of translating it to Windows myself. After that the instructions got better every now and then and I tried a couple of times more. Each time I got a few steps closer just to get annoyed to the point of ditching the idea for the next couple of months. I still don't have it set up, though I'd love to take a stab at some of the minor bugs that bothered me for a long time, yet have too low of a priority for someone to fix them.

    I'd love to be able to just do the work, attach a diff to the bug report (with a legal agreement checbox or whatnot) and let the module maintainer handle the bureaucracy.


  • Lifetime Qt Champion

    @Chris-Kawa What were the latest pain points that got you out ?


  • Moderators

    @SGaist The last time I tried was a couple of months back, so my recollection is a bit foggy. I think I stopped somewhere around running some perl scripts on the repo and messing up my whole git setup.
    Ok, I know what you're thinking - If you're not able to follow a couple of steps maybe it's a good thing you don't contribute, and I agree that it does a good job with outing some of the beginners. I do realize that some of the things I'll say sound very noobish, but I think that's a good thing in this context so please bare with me.
    The point is the whole procedure is kinda daunting if you're, like me, used to just entering git credentials in some login window and being done with it. I'll go over it a bit:

    • setting up ssh keys. I know - to most Linux guys this is kids stuff, but a seasoned Windows programmer is not used to that at all and copy/pasting some magic commands and editing .config files to do god knows what is kinda weird.
    • setting up git - again, to most Linux or command line hackers this is not worth mentioning, but the guide has something like 20 commands just to set up git. I remember half way through it I realized that all of them say --global somewhere in there and I just messed up other projects set up on my machine :/ Should've read that more closely I guess...
    • getting sources - when you think you're almost done there's another whole page on just how to get the source code! It involves running perl scripts!I'll better install perl... This might be silly but to someone that usually just presses a button in an IDE this is ridiculous. Basically when I read # updating each submodule to match the supermodule I thought "what the heck does that even mean?". Then there's the question of updating it, syncing etc. etc. Yet another few pages about how all of it is set up, what to pull, where to push etc. Installing git hooks?... An evening passed by.
    • then there's the short part about adding a gerrit remote, a link to how gerrit works aaaaand... h o l y c o w, yet another evening spent reading through this stuff...
    • and then, after all that, there's even no way to know if you didn't mess up somewhere. Just try to push something and hope for the best. Needless to say I did not get this far.

    Don't get me wrong. I don't want to sound bitchy. I know that to someone that already did it once and has a worked out steps for pushing stuff this all seems like just complaints of a noob, but I'm talking from exactly this noob perspective - a guy who is used to just clone, write code, push/make pull request, go eat some biscuits. Basically spending few evenings to work this stuff out, messing my machine's setup along the way, just to push a 3 line commit is just not something I imagined.



  • @Chris-Kawa said in Gerrit Contributions:

    Basically spending few evenings to work this stuff out, messing my machine's setup along the way, just to push a 3 line commit is just not something I imagined.

    IMHO this is the central point. If I have a small commit and have to spend 2 days to send it away I'll just give up.

    Ain't nobody got time fo that

    I KDE you create the patch file with git (3 clicks on GitExtensions), log-in click on submit for review and you are done


  • Qt Champions 2017

    @SGaist said in Gerrit Contributions:

    Tell him I'd be happy to review that although I can't give a +2 ;)

    The review is the last and smallest of the problems, I know you know. ;)

    Should we try to create a script that does the basic command line stuff leaving essentially the CLA and ssh key upload up to the user ?

    I really don't see how we'd do that. Even compiling Qt on Windows can get pretty hassly when one considers all the tools and possibly dependencies that have to be pulled from various sources.

    @VRonin said in Gerrit Contributions:

    his might lead to Qt devs to focus on major bugs and new features while, quite naturally, minor bugs (priority 3 or worse) remain hanging.

    And even then there's the possibility the patches are left hanging in gerrit.
    https://codereview.qt-project.org/#/c/165958/

    @Chris-Kawa

    Out of my own experience - the first time I tried to set up gerrit (was a few years back) I gave up because the process was very Linux-centric and I just couldn't be bothered to work out all the quirks of translating it to Windows myself.

    Even in that in mind it's pretty quirky. I'm by no means a git master but this thread attests the difficulty one can meet, even if an experienced developer.

    It involves running perl scripts!

    Yep, I had tried that on Windows with strawberry pearl, I gave up after a few hours of gloriously failing to make it work.

    and then, after all that, there's even no way to know if you didn't mess up somewhere. Just try to push something and hope for the best.

    I was literally terrified about this, @SGaist knows how that went as he was guiding me through it. I even thought I could break the remote repo ... not a fun time ...


    So back at the issue at hand, @tekojo had you the opportunity to ask if that proposition (made by one of Qt Company's employees if I recall correctly) went anywhere?


  • Lifetime Qt Champion

    @Chris-Kawa Not my line of thought at all. I'm really interested about what trouble can make a seasoned programmer like you abandon the idea of contributing. I thought that the fact that you are working on Windows could be part of it because setting up keys and such stuff on that platform is not as straightforward as it is from Linux or macOS as well as the build dependencies are usually completely absent by default from that platform.
    I've been through the ssh key setup process on Windows for other purpose and I thought afterward that I was pretty lucky when setting up for my first contribution on macOS even though at that time I found the process daunting. The documentation has improved but still, it's not as easy as anybody would like.

    @kshegunov I'm just throwing some ideas to to try to find a process that could bring difficulties down maybe have some sort of "Windows pack installer" that you could download to help you setup more easily for contribution.
    You should add a ping comment on your patch, that's what I usually do when it starts to stale.


  • administrators

    If you people don't mind, I'll just point our R&D management to this thread.

    It has a lot of familiar material in it, but the fact that we have very capable developers who find the process too complicated is something we really should be fixing.



  • @kshegunov said in Gerrit Contributions:

    And even then there's the possibility the patches are left hanging in gerrit.

    If patch is left hanging, it's your responsibility to bring attention of reviewers to it.

    Though we could have a "remind bot" that would post automatic message in case there is no activity on review in e.g. 2 weeks, and if nothing happens in the next 2 weeks after message, move patch to deferred state



  • Also we could have a reviewer suggestion bot that adds all developers that might be relevant for each patch that is hanging unreviewed for, say, more than 3 days.


  • Lifetime Qt Champion

    @tekojo as long as R&D doesn't mean Research & Destroy ;)

    @Konstantin-Tokarev I like the idea of the second bot. It can be pretty hard to know whether the people you try to select are currently active or part of the project.



  • BTW, in WebKit project we have configuration file that allows people to be added to review automatically if patch touches file matching specific patterns [1]. Gerrit has a similar feature for watching changes, but watchers are not publicly shown on the review page, so patch author cannot know whom to ping if there is no response.

    [1] https://github.com/WebKit/webkit/blob/master/Tools/Scripts/webkitpy/common/config/watchlist


  • Qt Champions 2017

    @SGaist said in Gerrit Contributions:

    You should add a ping comment on your patch, that's what I usually do when it starts to stale.

    @Konstantin-Tokarev said in Gerrit Contributions:

    If patch is left hanging, it's your responsibility to bring attention of reviewers to it.

    Will do.

    @SGaist said in Gerrit Contributions:

    maybe have some sort of "Windows pack installer" that you could download to help you setup more easily for contribution.

    Possibly feasible. I don't much work on windows, so our win users should feel free to correct me, but I think this should include setting up the git, somehow generating and uploading the ssh keys and probably installing perl with running the appropriate scripts. Do I miss something? Perhaps a set of dependencies?

    @Konstantin-Tokarev said in Gerrit Contributions:

    Though we could have a "remind bot" that would post automatic message in case there is no activity on review in e.g. 2 weeks, and if nothing happens in the next 2 weeks after message, move patch to deferred state

    Also we could have a reviewer suggestion bot that adds all developers that might be relevant for each patch that is hanging unreviewed for, say, more than 3 days.

    Both of those suggestions sound very good to me. What about adding a list of reviewers automatically on first patch upload (following the same logic)?


  • Moderators

    I know little of this is technically feasible (the amount of work to gain ratio) but just for the sake of an idea let me describe what I'd like the process to look like:

    • I open QtCreator (because why not?), from one of the menus I choose "Contribute"
    • I'm presented with a wizard that lets me login with my Qt account credentials and accept CLA
    • The wizard presents a list of development branches and modules I can check (like the Qt installer does), I select some
    • The wizard downloads stuff (source, dependencies, even git if needed!), sets up git (locally to the downloaded repos!) without me needing to do anything, creates the .pro files and I can just start hacking right away (Visual Studio does things like that so it's not really science fiction)
    • When I'm done I just push my changes to automatically set up remote and am presented a link to gerrit review page (gerrit integration into QtCreator would be a cherry on the cake).
    • Done

    Btw. Why do we even need perl? I mean maybe it was convenient to use in a linux environment but think about it - we have a giant c++ library, with its own language(QML), which has two custom build systems (qmake and qbs), its own IDE (QtCreator), two (or is it already one now?) Javascript engines, a networking and web browser engines and yet we still need a totally unrelated foreign language runtime just to download the sources. Sounds kinda eccentric.



  • @Chris-Kawa I think your process might move the problem on the other side of gerrit. Making it too easy to propose changes to the code might swamp code reviewers with changes that can't be accepted. Bots could filer out a few of them but probably the burden will increase significantly.

    I'd stick with a diff submission portal. preparing a git diff is the kind of thing a seasoned programmer considers trivial but it's not for a newcomer hence filtering out submission by people that might feel too confident in their Qt expertise.

    Same goes for the config. I'm not a fan of a 100% automated wizard but it shouldn't take more than 1 or 2 hours to set up the entire thing for a regular Qt user with decent git experience that is looking to contribute for the first time.


  • Moderators

    @VRonin said in Gerrit Contributions:

    Bots could filer out a few of them but probably the burden will increase significantly.

    I don't claim to have a silver bullet here but I think it's a better problem to have than not having as much contributions because of the process complexity.

    I'm not a fan of a 100% automated wizard but it shouldn't take more than 1 or 2 hours to set up the entire thing

    Sorry, but if it takes me two hours to set up a submission it might as well take 10, because I'm not gonna do it. I don't think using complexity as newbie deterrent is the way to go.
    A diff submission portal would be fine, but it solves only part of the problem. On Windows at least just getting the right sources with all the dependencies set up correctly (paths, environment variables etc.) is a chore.



  • @Chris-Kawa said in Gerrit Contributions:

    On Windows at least just getting the right sources with all the dependencies set up correctly (paths, environment variables etc.) is a chore.

    Agree it should be simplified a lot

    Sorry, but if it takes me two hours to set up a submission it might as well take 10, because I'm not gonna do it

    I did not explain myself correctly. What I meant is that from the moment I get the idea of submitting something (while still having only the binary of Qt on my machine) to the moment I submit it, it shouldn't take more than 2 hours (net, of course of the time I spend actually changing the sources) of goggling, reading, downloading setting up and sending. Subsequent submits (i.e. after I already set up my system) should be significantly faster.

    I don't think using complexity as newbie deterrent is the way to go.

    Probably not, it's the first thing that came to mind to mitigate the resistances of code reviewers, that can face a significant increase in their work burden, to the changes



  • @Chris-Kawa said in Gerrit Contributions:

    I don't claim to have a silver bullet here but I think it's a better problem to have than not having as much contributions because of the process complexity.

    Note that process may be complex only a first time, when you do your second or third patch you just use existing setup and execute simple git commands. If we make it possible to do "drive-by" contributions without setup, chances are that the person will continue using "drive-by" way, putting extra burden on reviewers.



  • @kshegunov said in Gerrit Contributions:

    What about adding a list of reviewers automatically on first patch upload (following the same logic)?

    It may create unnecessary noise. There are cases when you know for sure which person needs to review the patch, and there is no need to bother others (unless they are actively subscribed to this change by means of watch list)


  • Moderators

    @Konstantin-Tokarev First time is all it takes to drive a newcomer away. I'm not sure I understand your point. How is a drive-by contribution different from a regular one? The submission and approval process is the same for both. What's the point of limiting it apart from offloading the reviewers? Isn't having many submitters a good thing? Growing community should take priority over mitigating a side effect of its growth I think.


  • Qt Champions 2017

    @Konstantin-Tokarev said in Gerrit Contributions:

    It may create unnecessary noise. There are cases when you know for sure which person needs to review the patch, and there is no need to bother others (unless they are actively subscribed to this change by means of watch list)

    And unless the Qt Company is going to run an exclusive show then most of the time I, or any other unaffiliated/occasional contributor, scroll(s) down a list of git commit history entries and add(s) manually people to the list in gerrit. And to make it worse, I still have no idea whom I'm adding - is he/she active on gerrit, interested in reviewing, etc.
    So in fact I'm doing exactly that - bothering people, I don't see any difference between me doing it manually and it being automated.

    @Chris-Kawa said in Gerrit Contributions:

    First time is all it takes to drive a newcomer away. I'm not sure I understand your point. How is a drive-by contribution different from a regular one? The submission and approval process is the same for both. What's the point of limiting it apart from offloading the reviewers? Isn't having many submitters a good thing?

    And I think Chris took a stab at the heart of the issue, leaving the technicalities aside. I'm with him on this one. Isn't the point of Qt being distributed over LGPL to reap the benefits of that open source license, I'd think so, but then why insist on making the contribution process so deterrent that most potential submitters would prefer not to bother with it at all?



  • @kshegunov said in Gerrit Contributions:

    And unless the Qt Company is going to run an exclusive show

    As you can easily see, this is not the case, lots of people not affiliated with The Qt Company are contributors, approvers and even maintainers of modules.

    So in fact I'm doing exactly that - bothering people, I don't see any difference between me doing it manually and it being automated.

    There is a difference when you know whom to add.

    @Chris-Kawa said in Gerrit Contributions:

    I'm not sure I understand your point. How is a drive-by contribution different from a regular one? The submission and approval process is the same for both. What's the point of limiting it apart from offloading the reviewers?

    Because if you are not ready to invest a bit of time to learn git (and Gerrit does not use anything else) there is a risk that you won't modify your patches to fix reviewers' comments, or won't write unit tests when needed, or won't make sure that your code is ocmpatible with other platforms. In short, offloading work to approvers and maintainers. Sorry, if this is not the case for you.



  • @Konstantin-Tokarev said in Gerrit Contributions:

    Because if you are not ready to invest a bit of time to learn git (and Gerrit does not use anything else) there is a risk that you won't modify your patches to fix reviewers' comments, or won't write unit tests when needed, or won't make sure that your code is ocmpatible with other platforms. In short, offloading work to approvers and maintainers.

    I do see your point but drive-by would usually just act on small bugs, things you don't have time to fix because you, correctly, prioritise other stuff letting the odd user that is affected by the bug just fix it himself. This kind of contributors will probably have limited need to write platform-specific code or entire unit tests. things like this: https://bugreports.qt.io/browse/QTBUG-57925 which requires a either simple distribution of a parenthesis or a std::is_unsigned check (or both)

    Are we veering off track? I think the main point is configuring for contribution (primarily under windows) being too hard is preventing people from contributing altogether


  • Qt Champions 2017

    @Konstantin-Tokarev said in Gerrit Contributions:

    As you can easily see, this is not the case, lots of people not affiliated with The Qt Company are contributors, approvers and even maintainers of modules.

    It was a conditional, I'm not claiming they are. And your note, namely "There is a difference when you know whom to add." just supports it. The fact is that a new contributor doesn't know anyone out there, or they may not even care to, especially if it's a once-in-life thing. My point was that the review process shouldn't be an exclusive club for a group of people who know each other, right? The idea is that it'd be good to have smooth sailing irrespective of whether you're submitting your first patch or are a long-time contributor.

    there is a risk that you won't modify your patches to fix reviewers' comments, or won't write unit tests when needed, or won't make sure that your code is ocmpatible with other platforms.

    Suppose you're right. For one, as @VRonin hinted, no one is going to waste a day, or two only to submit a 5 line patch, it just ain't gonna happen. Not to mention commercial customers who are not even required to submit their changes, they can just sit on them forever. So even if we accept that there are enough people to handle the major things, they still have limited resources. It's been a complaint (I know you follow the mailing list, but some don't so I put it here for completeness) that there's accumulation of bugs and many just go unresolved for long periods of time. In my mind allowing more people to pitch in, should help alleviate that problem.
    And secondly, there's always risk. There's the risk a tree might fell on you while strolling through the park, this shouldn't stop you from having a walk, should it? Suppose it doesn't work in any of the proposed configurations, so what, what is there to lose?


  • Qt Champions 2017

    Resurrecting this thread due to Code contributions via bug reports and forum posts being allowed. Users are still encouraged to go through the usual route of setting up gerrit and the code review process however.



  • It would be nice to have a place in the forum where people could just post their “casual contribution” so that someone could pick them up while still being 100% covered under the Qt Account contribution model mentioned in the blog.
    Maybe a subforum of https://forum.qt.io/category/48/qt-contribution ?


  • Lifetime Qt Champion

    I'd rather avoid that. Threads on the forum tends to disappear over time and the patches would be really hard to associate with any given bug/problem.

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

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

    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.


  • Qt Champions 2017

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


  • Lifetime Qt Champion

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



  • @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


  • Lifetime Qt Champion

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


  • Qt Champions 2017

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


  • Moderators

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


  • Qt Champions 2017

    @kkoehne said in Gerrit Contributions:

    after the planned gerrit update...

    Cool. Are there any information about the planned update?


  • Moderators

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


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.