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

[Dave Mateer]

I don't know that my opinion matters much, as I'm just new on the
list. But I will confirm that the challenges below (and that others
have mentioned recently on this group) are very much the situation I
find myself in. I have about five patches I would like to submit for
bugs in JIRA, mostly priority 3 stuff. But I have already lost two
full days fighting Git and Gerrit and building Qt5. Some of the
instructions online are confusing or outdated. I understand that this
is still transitional and early, and many of those growing pains will
be resolved. And I have been nothing but impressed with the dedication
and commitment to excellence that the Qt team exhibits.
Nonetheless, if I could just submit my patches to something like JIRA
or hand them off to a "sponsor" of sorts that already has his
Git/Gerrit area configured and knows the idiosyncrasies of building
Qt5, that would make me much more inclined to contribute. As it is,
I'd like to just give up, but I feel like my acceptance of the LGPL
terms constrains me to at least keep trying a few more days. (We are
already using these patches in our production code.)
Again, not sure it matters much, but there is at least one case study
from someone on the "outside." :-)
Dave Mateer

On Wed, Dec 21, 2011 at 7:19 AM,  <marius.storm-olsen at nokia.com> wrote:
> On 12/21/2011 01:51 AM, ext Craig.Scott at csiro.au wrote:
>> On 21/12/2011, at 6:16 PM, Alan Alpert wrote:
>>> 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.
>
> Please keep in mind that the Jira bugtracker is still a Nokia service,
> until it is moved in under the Qt Project. (Given that Qt 4.8 is out, we
> can now start that process, but it hasn't happened yet. Lets wait with
> that until we have people back from Christmas vacation.)
> As such, it is still tied to the legal terms where we cannot accept
> *any* patches through Jira.
>
> Once moved to the Qt Project, trivial patches *could* be accepted as
> attachments, but it would then fall on the person with commit access to
> evaluate if the code he submits contains no patented code, and is
> otherwise free from copyrighted material. Do keep in mind that any (in
> most cases) employee which happens to make a patch to Qt and submit
> that, would in fact be submitting code which copyright belongs to his
> employer. He might not be allowed to do that, or simply not aware of
> this fact. Making contributors accept a CLA forces them to make a
> conscious decision about their contributions.
>
> So, once Jira is moved, it is *possible* to change the policy on Jira,
> the question really is *should we*?
>
> IMO, I think we can still live with no patches in Jira. Worst case, they
> can put it on a pastebin somewhere.
>
> --
> .marius
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development