Re: [Development] GitHub Pull requests

[Thiago Macieira]

On Wednesday, 11 March 2020 03:48:24 PDT Edward Welbourne wrote:
> Matthew Woehlke (10 March 2020 20:24) wrote:
> > In an ideal world...
> 
> [snip]
> 
> > Note that I believe nothing needs to be done to "merge" the GitHub PR;
> > if the commits become reachable from the target branch, it should
> > automatically get marked as "merged".
> 
> Given that gerrit cherry-picks the change submitted onto the branch it's
> sent to, the commit the user originally pushed doesn't become reachable.
> Will GitHub recognise the cherry-pick as resolving the PR ?

I doubt it. It doesn't recognise when I do that manually. It only recognises 
when GitHub itself dos the rebase prior to application. All other cases, the 
PR needs to be closed as if it got rejected.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Thiago Macieira]

On Tuesday, 10 March 2020 07:40:41 PDT Cristian Adam wrote:
> Hi,
> 
> With the “GitHub issues” E-Mail thread we made sure the Issues are gone
> from the projects.
> 
> What about Pull requests?
> 
> For example qtbase has 7 pull requests. 
> Usually people point out that
 the Qt project uses a different
> collaboration method:
> https://wiki.qt.io/Qt_Contribution_Guidelines
> 
> What stops us from accepting the contributions via GitHub?
> 
> Is it:
> 
>   1.  The CLA
>   2.  Qt Account

It is:
1. The CLA
3. The CI
4. We already have a review system, we should not have two.

You usay there's a way to have the CLA accepted in GitHub. Ok.

We ought not to have two places where code reviews happen for a specific 
module. That's just inviting sync issues. And this is assuming the CI is 
solved: right now, ours is the only authoritative entity that can push to our 
repositories in Qt. As far as I know, this is not a supported workflow in 
GitHub at all. It wasn't supported in Gerrit either before us -- we had to 
hire a consulting company to write the feature for us.

That only leaves having some modules switch wholesale   from our CI and from 
Gerrit to GitHub, using whatever review mechanism and CI can be obtained with 
GitHub, while other modules remain with Gerrit+Coin.

Why would we do that?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Konstantin Tokarev]

11.03.2020, 15:18, "Oswald Buddenhagen" :
> On Tue, Mar 10, 2020 at 02:40:41PM +, Cristian Adam wrote:
>> What about Pull requests?
>
> before you continue reinventing the wheel, i recommend that you read the
> comments on QTPM-314 (yes, all of them).

"You can't view this issue

It may have been deleted or you don't have permission to view it. "

Sure.


-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Alexandru Croitor]

> On 11. Mar 2020, at 07:48, Richard Weickelt  wrote:
> 
>>> In an ideal world...
>>> 
>>> - Alice opens a pull request on GitHub.
>>> - A bot sees the PR and opens a corresponding request on Gerrit.
>>> - Bob comments on the Gerrit request.
>>> - A bot sees Bob's comment and replicates it to the GitHub PR.
>>> - Alice replies (on GitHub) to Bob's comment.
>>> - A bot sees Alice's comment and replicates it to Gerrit.
>>> 
>>> ...and so on.
>> 
>> Then Bob asks Alice to make a change in commit, and she has to make
>> push -f in her branch. After that, review comments on GitHub are smashed,
>> while remain perfectly readable in Gerrit, and Bob can see difference
>> between patch versions while Alice cannot.
> 
> There is a github plugin for Gerrit that promises some form of integration:
> 
>https://gerrit.googlesource.com/plugins/github/

I searched a bit and found a sample github pull request, and its associated 
Gerrit change.

https://review.gerrithub.io/c/eclipse/titan.EclipsePlug-ins/+/486885
https://github.com/eclipse/titan.EclipsePlug-ins/pull/572

Looks like all commits inside the PR (2 in this case) + an additional commit 
for the merge get merged into Gerrit (rather than cherry-picked).

Don't know if it's configurable behaviour, somebody would have to play with the 
plugin.

> 
> It seems to be enabled on gerrithub:
> 
>http://gerrithub.io/
> 
>"GitHub pull requests
> Keep in touch with external users synchronizing
> pull requests with reviews."
> 
>"Pull requests with Gerrit
> Fetch your GitHub pull requests and upload them
> in Gerrit for review. Enable a single point of
> validation of the Code Review workflow and keep
> your external contributors up-to-date on GitHub."
> 
> I haven't tried it though. Does it work? Maybe there is a project on
> https://review.gerrithub.io/ where you can see github PR syncing in action.
> 
> Richard
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Oswald Buddenhagen]

On Tue, Mar 10, 2020 at 02:40:41PM +, Cristian Adam wrote:

What about Pull requests?

before you continue reinventing the wheel, i recommend that you read the 
comments on QTPM-314 (yes, all of them). you can open a task for the 
public gerrit component if you still feel revolutionary afterwards.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Edward Welbourne]

Matthew Woehlke (10 March 2020 20:24) wrote:
> In an ideal world...
[snip]
> Note that I believe nothing needs to be done to "merge" the GitHub PR;
> if the commits become reachable from the target branch, it should
> automatically get marked as "merged".

Given that gerrit cherry-picks the change submitted onto the branch it's
sent to, the commit the user originally pushed doesn't become reachable.
Will GitHub recognise the cherry-pick as resolving the PR ?

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Max Paperno]

Just wanted to chime in as a "could be" Qt dev. Lowering the barrier to 
entry by allowing use of familiar tools could be a benefit IF you're 
looking for more contributions. I'm sure there's effort involved to 
allow this, and maybe it's not practical in the end, but perhaps worth 
considering/looking into.


You could look at it as one step less than what's suggested in the 
Contributor Guidelines under "A Shortcut...":


"If you have only a minor contribution to make and find the process out 
of proportion for that, you may simply attach a patch to a bug report. 
However, the more of the necessary steps you defer to the code's 
maintainers, the less likely is your contribution to be integrated in a 
timely manner."


I did just that recently, submitted a short patch to the docs generation 
system via a bug report. Not a big deal, but it could easily have been 
an actual code commit w/out the extra step of someone needing to process 
the bug and apply the patch themselves... and some code got mixed in/up 
in the process so the final change was actually a bit less "clean" than 
what I had posted.


This could also be a "gateway method" for bringing the more serious 
contributors into the actual gerrit-based process.  ;-)


2¢,
-Max


On 3/10/2020 10:40 AM, Cristian Adam wrote:

Hi,

With the “GitHub issues” E-Mail thread we made sure the Issues are gone

from the projects.

What about Pull requests?

For example qtbase  has 7 pull 
requests.  Usually people point out that


the Qt project uses a different collaboration method:

https://wiki.qt.io/Qt_Contribution_Guidelines

What stops us from accepting the contributions via GitHub?

Is it:

 1. The CLA
 2. Qt Account

For the CLA one can simply add an instance of:

https://github.com/cla-assistant/cla-assistant

And it’s only one click away.

When I contributed to vcpkg, the process of signing the Microsoft

CLA was like that, one click.

Regarding Qt Account, maybe one can use the GitHub account to

create a Qt Account via openid.

With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate

the pull requests.

We should encourage developers to contribute to Qt, not having to learn

how to use gerrit, and using a workflow that they are familiar with, should

be a plus.

Cheers,

Cristian.



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Arttu Tarkiainen as approver

[Kari Oikarinen]

Seconding approver status proposals can officially be done by approvers
and maintainers. As far as I can see, Tino, you are not one, so this
doesn't count officially.

See 
https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-an-approver


+1 for Arttu's approvership.

On 11.3.2020 7.35, Tino Pyssysalo wrote:

+1

--

Tino Pyssysalo

Senior Product Manager

The Qt Company

On 10.3.2020, 14.00, "Development on behalf of Katja Marttila" 
 on behalf of 
katja.martt...@qt.io > wrote:


Hi all,

I’d like to nominate Arttu Tarkiainen as approver for the Qt Project.

Arttu has been working in the installer team as a SW developer since he 
joined the Qt Company about one year ago. First as a trainee and 
currently as full-time employee. Arttu has been focusing mainly to 
improve and maintain Installer Framework and proven to be very skilful 
developer. I’ll trust that he will use the approver rights responsibly 
and follow the Qt guidelines.


Here is the list of his changes:

     https://codereview.qt-project.org/q/owner:arttu.tarkiainen%2540qt.io

Br,

Katja Marttila

Software Engineer| Maintainer of Installer Framework

The Qt Company | Finland | Oulu


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development



--
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] GitHub Pull requests

[Richard Weickelt]

>> In an ideal world...
>>
>> - Alice opens a pull request on GitHub.
>> - A bot sees the PR and opens a corresponding request on Gerrit.
>> - Bob comments on the Gerrit request.
>> - A bot sees Bob's comment and replicates it to the GitHub PR.
>> - Alice replies (on GitHub) to Bob's comment.
>> - A bot sees Alice's comment and replicates it to Gerrit.
>>
>> ...and so on.
> 
> Then Bob asks Alice to make a change in commit, and she has to make
> push -f in her branch. After that, review comments on GitHub are smashed,
> while remain perfectly readable in Gerrit, and Bob can see difference
> between patch versions while Alice cannot.

There is a github plugin for Gerrit that promises some form of integration:

https://gerrit.googlesource.com/plugins/github/

It seems to be enabled on gerrithub:

http://gerrithub.io/

"GitHub pull requests
 Keep in touch with external users synchronizing
 pull requests with reviews."

"Pull requests with Gerrit
 Fetch your GitHub pull requests and upload them
 in Gerrit for review. Enable a single point of
 validation of the Code Review workflow and keep
 your external contributors up-to-date on GitHub."

I haven't tried it though. Does it work? Maybe there is a project on
https://review.gerrithub.io/ where you can see github PR syncing in action.

Richard
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development