Pushing To A GitHub Repository Post Commit

[PhistucK]

In order to encourage contributions to the Developer Tools feature, I am working on setting up a GitHub repository (a mirror of the Developer Tools JavaScript/HTML/CSS code) to which anyone could send pull requests (a Travis CI build bot - which is already set up with the help of Robert - will be testing the patch). Once approved by a team member, the pull request would be converted to a Rietveld issue and any future commit would turn into a new patchset.

This effort is, of course, coordinated with the Developer Tools team as well as Paul Irish.

As a part of this effort, I want to know if you are willing to provide the infrastructure for maintaining the mirror by pushing any relevant commit to a GitHub repository.

(I will provide as much code as I can for this, of course, but only you can create a post commit hook...)

I do not think I need the history (I do need the commit hash, I think, for dealing with Rietveld later). I was thinking to just clone the GitHub repository to some folder, copy the relevant source files from Blink to that folder, add everything, commit locally (with the same commit message, with an added original commit hash and push to GitHub. Pretty lightweight, I think. Unless you have other suggestions.

Thank you.

☆PhistucK

[PhistucK]

It might be, I am not sure what it entails and what the consequences are... But if this ends up in GitHub, then I guess it should work. :)

My proposal was meant to simplify things, but if this is simpler for you - beautiful. :)

This might complicate things -

I see that the Developer Tools feature (including its tests) is made up of a few paths.

blink/Source/devtools/*

blink/Source/core/inspector/*

blink/LayoutTests/inspector/* (and two additional similar paths)

blink/PRESUBMIT.py

Can the proposed way (subtree mirror) accommodate this?

Thank you!

☆PhistucK

On Wed, Jun 17, 2015 at 11:22 PM, Robert Iannucci <iann...@chromium.org> wrote:

We can do a subtree mirror from a subdirectory of a git repo into another git repo. Here's an example: https://chromium.googlesource.com/chromium/src/build

Would that suffice? Pushing it to github too would also be easy.

Rob

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABc02_JbpMnx6JB_xbjuAjKes%3DcaFjJqK8rKDifWgFdwr%3DANiQ%40mail.gmail.com.

[Robert Iannucci]

That would be pretty tricky... I would recommend refactoring it in blink into one subdirectory, if that's at all possible. Then you could have a single README at the base folder which makes sense and make it clear that it's extracted elsewhere and is expected to stand alone (so you don't introduce dependencies on code outside of the mirrored paths which work in blink, but not in the github repo).

We could also mirror Source/devtools, Source/core/inspector and Source/LayoutTests/inspector independently, and then make the github repo contain them as submodules (so the github repo would have 'devtools', 'inspector', 'inspector_tests' folders, and its own PRESUBMIT.py file). Then we'd need to write a bot to roll the submodules when they change.

Otherwise, it's possible that we could make the subtree daemon be able to extract multiple folders into single coherent commits.

I think it would be all-around better if we didn't need to do that, however :).

R

[PhistucK]

Andrey, can you advise here?

Thank you!

☆PhistucK

[Pavel Feldman]

>> This effort is, of course, coordinated with the Developer Tools team as well as Paul Irish.

As a DevTools lead, I don't think this is quite the case. It is the first time I hear we decided to do something on this front.

What is your plan here? This is not the first time it is brought up, but there are certain challenges on the way that prevented us from investing into it earlier. Namely, the review / contribution process execution with associated policy requirements and testing infrastructure that needs to run against the debugging backend.

Lets hold it off until discussed with the eng team.

Regards
Pavel

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CABc02_JSsDDYKW64LjrJ2K018BwV3q7fSfok_Qr0mdMd89%3DUnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[PhistucK]

So are you going to discuss this with the team and get back to me about this?

I was under the impression that this is acceptable, per the plan outlined by Paul Irish here -

https://groups.google.com/d/msg/google-chrome-developer-tools/5iLsW7T4m90/Qn-53A1LxGUJ

If it is not, please, advise.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAEX3KhYV1EYAfkyVjv_%2BK%2BfWgEb0ghDv1uqdHUj48wHBaPjPLA%40mail.gmail.com.

[Pavel Feldman]

No, it is clearly a bad idea. I don't see how it addresses the layout test issue, nor does it address review process challenges that we've faced with external contributors that start off github. So lets not fork the dev process like this.

We should instead steer the front-end itself towards a more open contribution model where it can be considered a standalone project with reasonable standalone testing harness and a way to test against runtime (i.e. no layout tests). So instead of forking and not testing, we should start with what we have and refactor it. That's however something we don't have free cycles for atm.

Anyhow, lets move this discussion back to the thread you pointed to.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CABc02_KGXzOH2ZrqQ7PHp-RWa28_hE8zLv69u4xTJ%3DffzSW-PQ%40mail.gmail.com.