idle thought: host code on github instead?

[Sam Berlin]

What do folks think of the idea?  It'd make accepting patches easier (with pull requests, etc), and I'm sure there's other benefits for folks using the code too.

We could also migrate issues if anyone knows a way to do that.

sam

[Nate Bauernfeind]

Yes please!

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.

[Stephan Classen]

+1

But how would you get changes from github back into the internal source control?

[Sam Berlin]

MOE... same way we do it now.  There's nothing special about codesite, it's just an arbitrary git repo.

 sam

[Christian Gruber]

I seem to recall there being a script to migrate issues, though it loses
a wee bit of fidelity in terms of comment authors.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Christian Gruber]

Oh, and I'm +1 on it. :)

On 27 May 2014, at 14:43, Nate Bauernfeind wrote:

[Mikhail Mazursky]

2014-05-28 2:31 GMT+06:00 Sam Berlin <sbe...@gmail.com>:

What do folks think of the idea?  It'd make accepting patches easier (with pull requests, etc), and I'm sure there's other benefits for folks using the code too.

We could also migrate issues if anyone knows a way to do that.

+1 of course!
 

[Thomas Broyer]

On Tuesday, May 27, 2014 10:31:37 PM UTC+2, Sam Berlin wrote:

What do folks think of the idea?  It'd make accepting patches easier (with pull requests, etc), and I'm sure there's other benefits for folks using the code too.

+1

 

We could also migrate issues if anyone knows a way to do that.

No need to do that IMO. You can just disable the "Issues" tab on GitHub to make sure issues cannot be reported in two places.

[Sam Berlin]

Unless folks strongly prefer the codesite issue tracker, I'd rather just move everything over to github (if possible).  Googling showed a few scripts people have hacked up to do the issue transfer, and I'm asking the codesite team if there's anything better around.

[david.o...@gmail.com]

Am Dienstag, 27. Mai 2014 22:31:37 UTC+2 schrieb Sam Berlin:

What do folks think of the idea?  It'd make accepting patches easier (with pull requests, etc), and I'm sure there's other benefits for folks using the code too.

I have to ask why not to move to:

 https://guice-review.googlesource.com

instead?

[Sam Berlin]

That link 404s, so I'm not totally sure what you're referring to.  googlesource.com seems to be the cover page for "open source stuff at google", which just links back to codesite.  Google already has an organization at GitHub (https://github.com/google), so this would just fit as another project in there.

sam

--

[Stuart McCulloch]

On 28 May 2014, at 14:58, Sam Berlin <sbe...@gmail.com> wrote:

That link 404s, so I'm not totally sure what you're referring to.

I think David was suggesting to use Gerrit at googlesource, like:

https://android-review.googlesource.com

Personally I’m +1 on moving Guice over to github

[david.o...@gmail.com]

OK, i thought it was clear.

I mean to host Guice development on Gerrit Code Review,

like Gerrit [1] itself and GWT library [2].

The code review process is much easier on Gerrit as on GH.

And of course you could still replicate to GH from Gerrit. That's what

Openstack [3], Wikimedia [4] and LibreOffice [5] projects are doing (read only).

I have added Shawn to this thread, as he is your man, should you decide

to go with Gerrit and create new site:

  https://guice-review.googlesource.com

[1] https://gerrit-review.googlesource.com

[2] https://gwt-review.googlesource.com

[3] https://review.openstack.org

[4] https://gerrit.wikimedia.org

[5] https://gerrit.libreoffice.org

[Sam Berlin]

Yeah, I see now.  I have nothing against using gerrit for code reviews if folks want to do that... but overall, I think hosting the project itself on GitHub is the best option.  GitHub just seems to have better community engagement tools.  We generally do most development of Guice internally (with internal code reviews) anyway, since changes have to be tested over the whole corpus.  For accepting occasional patches, GitHub just seems much easier... folks can easily fork, send a pull request, etc..  

 sam

[Sam Berlin]

Guava follows a different process than Guice.  I'd like to try and encourage more community development here.

 sam

On Wed, May 28, 2014 at 11:33 AM, Shawn Pearce <s...@google.com> wrote:

On Wed, May 28, 2014 at 8:31 AM, Shawn Pearce <s...@google.com> wrote:

On Wed, May 28, 2014 at 7:14 AM, Sam Berlin <sbe...@gmail.com> wrote:

Yeah, I see now.  I have nothing against using gerrit for code reviews if folks want to do that

We are more than happy to host Guice on Gerrit at googlesource.com, if that is where you want to host.

One advantage over GitHub is Gerrit inherently knows about contributor license agreements, and can make sure those are completed before the user even uploads a change to you for review. Its also hosted by Google, which gives us control over its uptime. :)

But checking CLAs isn't an issue if you aren't going to take the code.

... but overall, I think hosting the project itself on GitHub is the best option.  GitHub just seems to have better community engagement tools.  We generally do most development of Guice internally (with internal code reviews) anyway, since changes have to be tested over the whole corpus.  For accepting occasional patches, GitHub just seems much easier... folks can easily fork, send a pull request, etc..

Not sure how much this really matters. Guice is mostly developed internally at Google. Even there submitting patches from outside of the Guice team is... interesting. I remember spending a fairly long time to make a simple bug fix in one of the Future wrappers. The team has very high standards, which I really do enjoy as a consumer of the library. :)

Sorry, I haven't bootstrapped with caffeine yet this morning. I think I meant Guava above. I haven't contributed anything to Guice because I have been lucky enough to never find a bug. :)

[Shawn Pearce]

On Wed, May 28, 2014 at 7:14 AM, Sam Berlin <sbe...@gmail.com> wrote:

Yeah, I see now.  I have nothing against using gerrit for code reviews if folks want to do that

We are more than happy to host Guice on Gerrit at googlesource.com, if that is where you want to host.

One advantage over GitHub is Gerrit inherently knows about contributor license agreements, and can make sure those are completed before the user even uploads a change to you for review. Its also hosted by Google, which gives us control over its uptime. :)

But checking CLAs isn't an issue if you aren't going to take the code.

... but overall, I think hosting the project itself on GitHub is the best option.  GitHub just seems to have better community engagement tools.  We generally do most development of Guice internally (with internal code reviews) anyway, since changes have to be tested over the whole corpus.  For accepting occasional patches, GitHub just seems much easier... folks can easily fork, send a pull request, etc..

[Shawn Pearce]

On Wed, May 28, 2014 at 8:31 AM, Shawn Pearce <s...@google.com> wrote:

[Michael Burton]

+1 for github

Mike Burton

RoboGuice

http://about.me/michaelburton

[Christian Gruber]

I'm happy enough with the github issues list - I've played enough with
tags that I have found a nice balance on some other projects.

c.

[Christian Gruber]

Agreed on all counts. Though we already have a process for CLA
management in google, though that's a good feature request to ask of the
github folks.

c.

> --
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-guice...@googlegroups.com.
> To post to this group, send email to google...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Wednesday, May 28, 2014 10:25:36 PM UTC+2, Christian Gruber wrote:

Agreed on all counts.  Though we already have a process for CLA
management in google, though that's a good feature request to ask of the
github folks.

Something like https://www.clahub.com/ ?

[Christian Gruber]

Wait, Thomas... didn't we have this conversation about a year ago? :D I
seem to recall you mentioning this.

But I actually think hosting a CLA isn't what I'm looking for so much as
being able to tie in your own association of "CLA-signers" to github
users, so there can be some signal as to whether that person's code can
be safely merged... but not necessarily basing that signal off of
someone else hosting that CLA info.

I can see CLAhub being useful for independent projects, but for
google-wide open-source contributions, we have our own CLA (and storage)
and a clean integration there would be good.

(That said, it's a cool project, though blog.clahub.com 404s, yet is
referred to in the main page)

c.

On 28 May 2014, at 15:36, Thomas Broyer wrote:

> https://www.clahub.com/

[Sam Berlin]

Wow, that's a lot of permissions it requires on the project.

--

[Will Norris]

GitHub's API already provides all the pieces to make this possible... I assume that's what clahub uses, we just haven't built it all out yet for Google-owned projects.  Gerrit has CLA checks today, Google projects on GitHub will have them... eventually. :)  The Angular team has an Apps Script hack that is tiding them over in the meantime... that could possibly work if you really needed it.

[Christian Gruber]

Can you point me at it Will? I would love to implement that for a few
projects in the short term until something more comprehensive is in
place.

c.

>> email: cgr...@google.com <javascript:> :::: mobile: +1 (646) 807-9839

>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-guice...@googlegroups.com.
> To post to this group, send email to google...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

AFAICT, CLAhub uses the statuses API (the same that Travis CI also uses): https://developer.github.com/v3/repos/statuses/

You can find the CLAhub code at https://github.com/clahub/clahub

To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscribe@googlegroups.com.

To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency Injection

email: cgr...@google.com :::: mobile: +1 (646) 807-9839

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Will Norris]

https://github.com/angular/google-cla-verifier-for-github it's a bit of a hack, but seems to work for them.  

It needs a GitHub account to run as (for commenting on pull requests to point people at the CLA).  We setup https://github.com/googlebot for exactly that sort of thing, so I'll follow up offline on getting you access to that.

To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscribe@googlegroups.com.

To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.

[Sam Berlin]

Awesome.  Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.

[Sam Berlin]

FYI -- I've made some progress on this for issue migration.  Starting with https://github.com/arthur-debert/google-code-issues-migrator as a base, I've hacked it to upload text-based attachments as gists (and only link the binary attachments back to codesite, since there's no way to put binary attachments to issues on github that I know of).

I'm running a trial over https://github.com/sameb/guice-test/issues now... the script flakes out every so often because github's API seems to return bad response, so it needs a bit of babysitting to restart... but it recovers well (without duplicating any data).

Take a glance over the issues in the test repo and let me know if you think anything needs changing.  If everything looks good, I'll do the actual migration this week.

And happy July 4th, everyone!

sam

On Tue, May 27, 2014 at 4:31 PM, Sam Berlin <sbe...@gmail.com> wrote:

What do folks think of the idea?  It'd make accepting patches easier (with pull requests, etc), and I'm sure there's other benefits for folks using the code too.

We could also migrate issues if anyone knows a way to do that.

sam

[Christian Gruber]

Awesome.  Thanks Sam.  I think this will be a great situation once we've made the transition.  Looking to migrate Guava at some point this quarter, in all likelihood.

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAJEBNUcSC-WGwri-0Vjj1Sj%2BWNuqRy0Agbp7AM_BVTeDyXq-UA%40mail.gmail.com.

[Sam Berlin]

So in reviewing, there's a few things I want to fix up. The markup in GitHub interprets a bunch of stuff differently, so I'll need to escape a few things.

Does anyone know how to escape an @ so it's not interpreted as an @mention?  I tried a bunch of things, but only putting in code blocks worked... and that ruins the flow a bit, unless the entire comment is a code block (which induces horizontal scrolling).

sam

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHsNDCQM0G8X1c8EKQunKUQn8JJ_3dDVHoGZZE1Ygj2c7Rk6Gg%40mail.gmail.com.

[Christian Gruber]

Back-ticks.

`this is a code bit`

C

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAJEBNUc75HTFfp_exwz%2BV21BGi%3Da1Wt7oKik_VPNtosEX86d0A%40mail.gmail.com.

[Sam Berlin]

Yeah, that'll put it in a code block.  I'm hoping there's some way to escape the @ without putting it in a code block, though, since code is visually very different.  You can escape # and things by using \, but \@ doesn't seem to work.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHsNDCR7j%2BPqZD_LfgqR8vxvwaaPKm9A%3DujBVzY%3D%2B_ksKGKwdA%40mail.gmail.com.

[Christian Gruber]

Ohhhh.   I see. You don't mean a multi line code block, you mean any code block.  Yeah, I know of no way.

If they're annotations then they should be in a code block.   that's appropriate because they're code. If they're not annotations, then I am vaguely confused.  :)

I'd just use back ticks and call it a day, frankly.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAJEBNUfL%3DCiEboD_YUeergwsQxHGXLKo-4nLwZs10S-D%2B0MhhA%40mail.gmail.com.

[Sam Berlin]

Fair enough.  I did a few more cleanups on the script, so whitespace (e.g, indentation) is preserved, and other characters are escaped to prevent markup from changing it.  Should be pretty set now.

sam

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHsNDCQT48Gpt4R7rzbTH9Dk6tv6hhEgLvaaJt%3D%3DdrBGEeP7KQ%40mail.gmail.com.