[Development] Patches in JIRA (Was: (no subject))

[Craig.Scott at csiro.au]

On 21/12/2011, at 6:16 PM, Alan Alpert wrote:

> On Wed, 21 Dec 2011 16:52:54 ext Craig.Scott at csiro.au wrote:
>> On 21/12/2011, at 5:14 PM, Robin Burchell wrote:
>>> On Wed, Dec 21, 2011 at 2:57 AM,  <Craig.Scott at csiro.au> wrote:
>>>> On 21/12/2011, at 12:19 PM, <mark.keir at nokia.com> <mark.keir at nokia.com> 
> wrote:
>>>>> Posting patches to the JIRA bugreporting system is contrary to the
>>>>> terms of use for that system.
>>>>> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html Don't
>>>>> do this.
>>>> 
>>>> I know I'll probably be shot down immediately, but.....
>>>> 
>>>> This is one of the more annoying things about the changes that have been
>>>> going on with Qt.
>>> 
> [...]
>>> [ that having been said, I agree that it's really annoying, but I
>>> can't really see a nice method to solve this, other than possibly
>>> directing them to accept the CLA on gerrit the first time they upload
>>> a patch to JIRA, but that's going to require customisations.. and in
>>> the end, it's probably better to focus on streamlining the
>>> contribution & review process we have first ]
>> 
>> I'd actually suggest the reverse. I would hope that it would be a
>> relatively non-disruptive change to make JIRA aware of who has accepted
>> the CLA and who hasn't. It should be possible to do this without any
>> developers having to know about it. If that is done, then there are no
>> more steps required to allow anyone who wants to submit a patch to do so.
>> In contrast, getting the contribution process in place for gerrit looks
>> like more work and targets a smaller number of users (everyone could
>> submit a patch, but only those willing to learn the process would submit
>> via gerrit).
> 
> Even if it's an easy change, do we even want those patches via JIRA? For 
> trivial patches  I don't think the CLA applies anyways, for non-trivial 
> patches there needs to be discussion and code-review (and CI at the very 
> least). Gerrit is what does this for us at the moment, and it's much better 
> suited for it than JIRA. 

Yes it applies to trivial patches too (at least, I've had trivial patches redirected to the git merge request process in the past). I don't really see the down side here. You are choosing between no patch at all and a patch that the maintainer can choose to use or not. Nothing lost, but potentially something gained.

There will still be discussion and code review when whoever picks up the patch puts it through the gerrit system. It's not replacing the process, it's about giving the maintainer a more advanced starting point to fix the issue.

> 
> I can't imagine that there are many high-quality, large submissions, all ready 
> to merge, from a submitter that doesn't know git/gerrit yet. If gerrit really 
> is that hard to use, wouldn't it be better (and probably easier) to fix gerrit 
> than duplicate its functionality in JIRA?

It's not just gerrit, it's also git and understanding the repository structure. Plenty of people still like svn, for instance, and maybe their day job doesn't require them to know git or gerrit or the internals of Qt beyond the small bit they investigate for a bug that's relevant to them. I would not be so hasty as to assume that just because a developer hasn't worked out git/gerrir/repo structure, their work won't be of a high quality. The size of the submission isn't really important here.


--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia