Gerrit Contributions
-
@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)
@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?
-
@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.
-
@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_unsignedcheck (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
-
@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:
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? -
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 ? -
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.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
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.
@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 ...
Read and abide by the Qt Code of Conduct
-
@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:
@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.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@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
-
@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
