Live data from Hacker News

Bidding farewell to Google Code

google-opensource.blogspot.com

311–320 of 428 posts

Re: Bidding farewell to Google Code

#311
post #275

Earlier quoted context omitted.

I think that's because you are promoting the Gitlab Enterprise edition. It is very easy to miss the third blurb which promotes the free repos. Compare this to bitbucket.org front page (Free private repos are upfront). Github.com frontpage is not as clear but they don't need to I think what Gitlab.com needs is a template like this - Free Private Repos - Host it on Gitlab.com - Need to host it on your servers? Get our…

Thanks for the great feedback! I've changed the homepage according to your feedback in https://gitlab.com/gitlab-com/www-gitlab-com/commit/3a09175f... https://about.gitlab.com/gitlab-com/ mentions that it runs the enterprise edition in the middle box The pricing page is a hard one, we'll look into that. Any idea how we can make the three blurbs on the homepage feel more like different products?

Btw my suggestions were just a template. I'm flattered that you used them as is :)

1. For the blurbs - remove the icons and add headers. Something like this - https://cloudup.com/cGSjRmrWGkU

2. Gitlab.com as a product name is very confusing. When I first checked out gitlab.com my thought was "I'm already on gitlab.com, what's this other gitlab.com" :) So I have changed it to Gitlab Hosted to make it more clear

Other Potential Improvements

This section - https://cloudup.com/c4vipl-QFBU tries to do everything. Explain features, introduce 3 different products and has a lot of text that could be removed

I would suggest making the entire block about features but in a layered way. i.e first introduce common features and then differentiate the products.

Some text could be removed - Subscriptions blurb can be replaced by "See our enterprise pricing page for subscriptions" or something similar. The way it is laid out now, it seems it is separate from Github Enterprise.

The current feature text blurb is too much text and too little text at the same time :) Too much because it is just long lines of text. Too little because none of your features are explained elegantly. There is also a "much more" syndrome :)

Just see - https://about.gitlab.com/features/ - Powerful Code review - "Merge requests with line-by-line comments, CI and issue tracker integrations and much more" with a giant image. Text doesn't say much and ends with an ambiguous "much more" and the image is intimidating unless you are familiar with Gitlab.

Compare that to Pull requests section of stash "https://www.atlassian.com/software/stash?utm_source=bitbucke...

Images are not much help but they help in avoiding a wall of text and all the sub features are explained

The actual experience of using Bitbucket is not that great but they are doing a good job of explaining features :). Github enterprise also does something similar.

I think you should also move "Better than Github" to a different section like say "Why use GitLab?" Having it right at the top seems very defensive and a bit distracting.

One last thing - Link to some interesting projects using Gitlab and make it easy to find. You can even link to Gitlab.org somewhere. Looking around a repo gives a better feel for the product.

Re: Bidding farewell to Google Code

#312
post #171

Ugh. No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate. What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth o…

Chris diBona says Google will be keeping a public copy of all unmigrated repos:

https://news.ycombinator.com/item?id=9192554

Re: Bidding farewell to Google Code

#313
post #196
post #171

Ugh. No, not that Google Code is shutting down, per se. The alternatives are better and for active projects there is plenty of time to migrate. What I object to is that the site will only be preserved in read-only mode for 5 months, despite its popularity and the resulting large number of deep links into it on the Web. Why not forever? git, hg, and I believe svn can all provide read-only access (with some bandwidth o…

Google hates anything that requires a human's touch, and per the article: > Lately, the administrative load has consisted almost exclusively of abuse management. They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would r…

> Google hates anything that requires a human's touch

I guess robots will soon make decisions in Google too ;)

Re: Bidding farewell to Google Code

#314

Earlier quoted context omitted.

> On what planet is shutting down a service, with months and months of notice, evil? The current planet? Open source projects have a lifetime of years so five months is not that long in the scheme of things. People put there code on there and participated (providing Google content that they were able to use and drive traffic) with the expectation that it would be there for the long term.

This is a rather watery definition of evil. It is fairly close to saying a restaurant is evil for not keeping a menu item you like.

> It is fairly close to saying a restaurant is evil for not keeping a menu item you like.

Actually closer to saying they are evil for destroying humanity's only copy of the recipe.

Re: Bidding farewell to Google Code

#315
post #262

Earlier quoted context omitted.

> GitLab is faster in on some pages. The commit page probably is slower, but not by so much: For the initial HTTP request maybe and if you're in the US. Gitlab is painfully slow when loaded from a European network connection and you factor in the time it takes to fetch all resources. Cached or uncached. > GitLab doesn't have preview support for as many features as GitHub, but it has many other features GitHub doesn't…

Right now GitLab is hosted in Germany (AWS Frankfurt) and I was testing from the US (Mountain View). But I sometimes see the same delay you mention. We'll move it to the US east coast over the next couple of months. I think protected branches are really nice for open source projects too, although I agree that most contributions will come from forks. Right now no open source projects use Git Annex but that might chang…

Out of curiosity, why Frankfurt?

Speaking as a European, it would be nice if you could keep it performant over here too ;)

Re: Bidding farewell to Google Code

#316

Earlier quoted context omitted.

It is a very nice system, but the stuff that goes into a shutdown had me fighting to keep the message as tight as possible. I wanted to go on about Bitbucket, gitlab, and put in a long discussion about how this doesn't effect the scalable git team at google at all (we host android and chrome and a ton of internal teams on a git backed on our backends here) , but had to keep the message pure... But I heartily recommen…

Hey look! You get to put "I heartily recommend people look at Gitlab - Chris DiBona, Google" on your homepage. That you haven't yet is mindboggling.

Totally agree. And even better, we put your quote about Chris his quote on there together with you HN profile :) See https://gitlab.com/gitlab-com/www-gitlab-com/commit/7eb4ced6... and https://gitlab.com/gitlab-com/www-gitlab-com/commit/b9342fd5...

(if you'll get in trouble for this please say so here or via sytse@gitlab.com and I'll remove it ASAP)

Re: Bidding farewell to Google Code

#317
post #283
post #276

This makes me question: how important does Google see developers as being as part of their ecosystem? I mean, I understand all the rational logic of what they are saying. Sure, there are other services etc etc, the world will keep turning. But doesn't Google see any kind of benefit from having developers using their service? In terms of mind share, having developers think positively about Google, having them regularl…

Google wants developers contributing to their projects, so they go where the developers go. The developers have moved onto GitHub and have effectively abandoned Google Code, therefore so has Google. Stubbornly maintaining their own service no one wants just breeds confusion and and a division of resources. As the article says: > To meet developers where they are, we ourselves migrated nearly a thousand of our own ope…

That all sounds weak to me. Google largely abandoned Google Code before all the developers fled to Github. One of the reasons people went to GitHub because it was clear that Google was no longer investing in Google Code. You're painting a picture where Google is just a passive entity that has no control over what developers do, it just meekly follows them around. That is hardly giving an impression that developers are a high priority to Google. If they were a high priority, Google would want them all using a Google service, and be willing to invest in that to keep them there, not cede them to third party.

Re: Bidding farewell to Google Code

#318
post #2

Hi everyone. I wanted to let you know (and I know this isn't a huge surprise) that we will be shutting down the Google Code project hosting system over the next year. Wired did a nice story about Github that touches on the shutdown: http://www.wired.com/2015/03/github-conquered-google-microso... I'll be hanging around answering questions, but the short form of 'why' is that it just isn't used much anymore, ourselves…

Are there any alternatives that allow the use of SVN? I use Google Code to store my Skyrim mods-- because Skyrim mods heavily depend on being in the Skyrim folder structure, I need to have them on SVN (or TFS, I guess) so I can create "sparse" repos. Git doesn't allow this.

Re: Bidding farewell to Google Code

#319
post #93

Earlier quoted context omitted.

It's true that Google does not use Google Code for any coding project anymore, but it's still used as a support interface. For instance if you want to file bugs for AppEngine the official way is through Google Code https://code.google.com/p/googleappengine/issues/list What are the plans on moving this and other issue lists for different Google products out of Google Code?

PM on App Engine here. We'll continue to be using (and monitoring) the Google Code issue tracker until we have a robust alternative available. We have plans for this, we're just not ready to talk about them yet.

Is this a plan just for AppEngine or for all other Google Products that use Code as an external Issue Tracker?

Re: Bidding farewell to Google Code

#320
post #262

Earlier quoted context omitted.

Right now GitLab is hosted in Germany (AWS Frankfurt) and I was testing from the US (Mountain View). But I sometimes see the same delay you mention. We'll move it to the US east coast over the next couple of months. I think protected branches are really nice for open source projects too, although I agree that most contributions will come from forks. Right now no open source projects use Git Annex but that might chang…

Out of curiosity, why Frankfurt? Speaking as a European, it would be nice if you could keep it performant over here too ;)

Because Frankfurt was close to Delft and we wanted to reduce latency to move the data, see https://news.ycombinator.com/item?id=9171533

We think the east coast of the US is the best compromise considering our user base. Can't solve speed of light :/

Post reply on HN