redirect / to http://shields.io/

[chadwhitacre]

Reticketed from #36. Sounds like we're going to do the redirect in HTTP instead of HTML. Also some question as to our repo organization ...

[nathany]

I'm not sure where DNS is for http://b.adge.me/ but fyi many DNS services (such as DNSimple) support HTTP redirects, no need to have a little server running for it (unless we want to rewrite some parameters for API changes?).

[chadwhitacre]

@nathany Good call. In this case we're talking about the API server redirecting /, and the API server will be running anyway (not just a dedicated redirect server).

[espadrine]

Fixed by 8f84eef.

[chadwhitacre]

Not deployed yet?

[chadwhitacre]

I'm still getting a 200 from http://img.shields.io/.

[chadwhitacre]

$ curl -I http://img.shields.io/
HTTP/1.1 200 OK
Content-Type: text/html
Date: Tue, 11 Feb 2014 12:28:06 GMT
Last-Modified: Wed, 05 Feb 2014 12:53:02 GMT
Connection: keep-alive

$

[espadrine]

It isn't deployed yet. I figured I should deploy it after I got a reaction to badges/shields#117 (comment).

[espadrine]

@whit537 I have deployed things such that this redirection is no longer necessary. Indeed:

The website is located at the root of the repo (index.html, logo.svg, favicon.png).
Therefore, http://badges.github.io/gh-badges/ contains the proper site.

We thus have the following properties:

• The repo contains consistent website code and server code at all times,
• Pushing to gh-pages and deploying can be automated as a single command,
• shields.io/ can redirect to gh-pages, which is the same as img.shields.io/,
• The server can serve its own index, which is also the same as both gh-pages and img.shields.io.

@whit537 @olivierlacan can you make shields.io redirect to http://badges.github.io/gh-badges/? It will make deployment much easier and ensure consistency.

I will then remove the server (img.shields.io) root redirection, since it will no longer be needed.

[chadwhitacre]

@espadrine Sorry, I don't like this setup. :-(

The purpose of my involvement with Shields is to try to fund an open-source service using Gittip. I'm less concerned about repo layout, but I do think we need the following:

1. http://shields.io/ with first impression marketing pages, that drive people to pay for Shields via Gittip.
2. http://img.shields.io/ as the actual web API

I consider the page we currently have at http://shields.io/ to be a step in the right direction, but in my view we haven't yet begun to work on (1). We started trying on #92 but that has stalled out. The backend is settling down after our move to gh-badges. It's time to figure out how to restart our branding and design/marketing effort.

Specifically, I'm a big -1 on redirecting http://shields.io/ to http://badges.github.io/gh-badges/, because that would seriously weaken the Shields brand. It's already weak enough! We need to strengthen the Shields brand, not weaken it!

[espadrine]

I'm trying to fix a current issue that I'm getting pinged for. That issue is that http://shields.io is out of date. It will get more and more out of date with time.

I have no issue with having a better marketing information in http://shields.io in the future. Since you wish http://img.shields.io to hold the actual web API, it would make sense to put exhaustive information about it in http://img.shields.io/index.html. I see no reason why both websites should show the same information forever. In that case, redirecting http://img.shields.io to http://shields.io is no longer necessary (and in fact actively contributes to the brand fragmentation which you wish to reduce).

[chadwhitacre]

I'm trying to fix a current issue that I'm getting pinged for. That issue is that http://shields.io is out of date. It will get more and more out of date with time.

I just double-checked: I believe you have access to push to the badges/shields repo, yes? Is there a reason not to update the file in the gh-pages branch there?

I see no reason why both websites should show the same information forever.

Agreed. I believe the information should be kept in one place: http://shields.io/. :-)

it would make sense to put exhaustive information about it in http://img.shields.io/index.html

I think it would make more sense to have the web API docs at http://shields.io/docs/ (or something like that), in order to maintain consistent branding with the rest of the http://shields.io/ site by using the same templating and being integrated into a single information architecture for navigation.

The reason to keep the API server on a separate domain from the marketing pages is that "it allows [us] to do more interesting things on the api endpoint if/when necessary (rate limiting, caching, etc.) that do not affect the marketing pages" (@nbibler at badges/shields#52 (comment)).

In that case, redirecting http://img.shields.io to http://shields.io is no longer necessary (and in fact actively contributes to the brand fragmentation which you wish to reduce).

I'm not seeing this. If I learn about Shields from Twitter or whatever, I'm going to see a link directly to http://shields.io/. If I learn about Shields from the src of an image, then I may manually enter http://img.shields.io/, and I'll be taken to http://shields.io/. Where's the fragmentation?

When I view source on a Twitter profile pic and see https://pbs.twimg.com/profile_images/378800000364460013/764889e54498c073acf5d628f4c4b126_bigger.jpeg I don't expect to find something on https://pbs.twimg.com/. At most I might expect a redirect. Gravatar uses http://www.gravatar.com/avatar/28d77b070cbc2bb40b404e1f5b0e64fa for images, and redirects http://www.gravatar.com/ to http://en.gravatar.com/ (or other languages, presumably).

Humans and computers have different needs, and using different domains allows us to best serve their respective needs.

[espadrine]

I just double-checked: I believe you have access to push to the badges/shields repo, yes? Is there a reason not to update the file in the gh-pages branch there?

I'm trying to make it easy for contributors to test this. If the deploy script specifically requires badges/shields access to check that the website looks ok, they won't contribute, and it isn't very welcoming to start with.

Let me explain the current state. Testing the website requires to run the server and go to http://localhost/try.html. If it looks ok, you then make website (or simply make deploy), which builds index.html, and it automatically uploads it to gh-pages.

If you really want Shields to be known as http://badges.github.io/shields/, the only result will be that someone will become the official website updater. If that is what you want, you can close this bug, because it is the current state, and the website will always lag behind until I remember to update it.

[chadwhitacre]

If you really want Shields to be known as http://badges.github.io/shields/

Where is this idea coming from? I think http://badges.github.io/shields/ should redirect to http://shields.io/ (and I'm not sure why it doesn't).

until I remember to update it

Unless we move the code from gh-badges/master to shields/master. :-) This brings us back to badges/shields#117 (comment), in other words.

I agree that the process of updating http://shields.io/ to reflect whatever is actually available on http://img.shields.io/ should be automated. I think that the make website dance we're doing now on gh-badges is fine for the time being (we may need to revisit once http://shields.io/ is further along). If we move gh-badges/master to shields/master then we can use that process or something like it, no?

[espadrine]

Where is this idea coming from? I think http://badges.github.io/shields/ should redirect to http://shields.io/ (and I'm not sure why it doesn't).

Okay, there's something very precise which either I or you don't understand about the current situation. Since I don't know which it is, I'll tell you what I understand.

Currently, http://shields.io is just a domain name that costs nothing. It has no hosting. Hosting is provided by GitHub through this weird hack that we use by redirecting shields.io to http://badges.github.io/shields.

Since I have no control over shields.io (the DNS), I cannot check that I am right. Who can?

Unless we move the code from gh-badges/master to shields/master.

That would confuse / annoy contributors, so it's not a small change, it needs to be discussed and acknowledged a great deal. Think of all the issues to be copied across, all the people to ping if they want to stay subscribed to those issues. Besides, shields/master seems to be used for many varied things that don't relate to the actual code. If I recall, we decided to dedicate it to design decisions.

[chadwhitacre]

Okay, there's something very precise which either I or you don't understand about the current situation.

You were right, our DNS for shields.io was misconfigured. Sorry about that. :-/

I cannot check that I am right.

Sure you can. :-)

$ dig shields.io

; <<>> DiG 9.8.5-P1 <<>> shields.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60207
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;shields.io.                    IN      A

;; ANSWER SECTION:
shields.io.             3473    IN      A       50.31.209.254
shields.io.             3473    IN      A       199.27.76.133

;; Query time: 5 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Tue Feb 18 15:30:03 EST 2014
;; MSG SIZE  rcvd: 60

GitHub owns the 199.27.76.133 IP address and uses it for GitHub pages (I see a GitHub pages 404 there). We have an ALIAS record for shields.io to badges.github.io. ALIAS is a DNSimple extension to provide CNAME-like functionality on the apex domain:

The ALIAS record will automatically resolve your domain to one or more A records at resolution time and thus resolvers see your domain simply as if it had A records.

So that's all good.

On the other hand, 50.31.209.254 does not resolve to GitHub pages. I went fishing, and it turns out that I neglected to delete the URL record for shields.io. This is another DNSimple extension that implements 301 redirect functionality. Presumably 50.31.209.254 is owned by DNSimple and results in a redirect.

Hosting is provided by GitHub through this weird hack that we use by redirecting shields.io to http://badges.github.io/shields.

So, yes: depending on which A record you were getting from DNS, you could very well have still been getting the redirect from http://shields.io/ to http://badges.github.io/shields/.

I've now removed the URL record, and dig is running clear:

$ dig shields.io

; <<>> DiG 9.8.5-P1 <<>> shields.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17159
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;shields.io.                    IN      A

;; ANSWER SECTION:
shields.io.             3595    IN      A       199.27.78.133

;; Query time: 1 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Tue Feb 18 15:55:20 EST 2014
;; MSG SIZE  rcvd: 44

$

However, since the redirect was a 301 (sadly), you may need to clear your browser's DNS cache before seeing http://shields.io/ resolve properly.

Hopefully that clears that up. :-)

[chadwhitacre]

Think of all the issues to be copied across,

I count nine issues (including this one).

all the people to ping if they want to stay subscribed to those issues.

I count eight unique participants across the nine open issues.

I guess that doesn't seem like a lot to me. :-)

Besides, shields/master seems to be used for many varied things that don't relate to the actual code. If I recall, we decided to dedicate it to design decisions.

The master branch has a storied past, yes. Right now we're not doing much of anything with it. We were talking about using it for the code for a go-based API server when you showed up with gh-badges (see badges/shields#91 (comment)). So I think moving the gh-badges code to shields/master makes sense from the pov of where we were headed with the master branch before.

so it's not a small change

I think mostly you're just dragging your feet, because gh-badges is your creation, and you're reluctant to see it subsumed under the Shields brand. :-)

Of course, that's not a small change. Do you believe in the Shields brand? Based on the past month or two, do you want to keep working together to move forward with the Shields brand? :-)

[espadrine]

gh-badges is just a name. I only care about doing things that matter and that make everybody's life easier. I wrongly assumed that the reason you disliked shields.io redirecting to http://badges.github.io/gh-badges/ (instead of http://badges.github.io/shields/) was so that we would redirect to something that had a "shields" in the URL.

Since that wasn't the reason, I'm not sure what was. If http://shields.io can do an ALIAS on an apex domain, the target is irrelevant; we can pick whichever is easiest. (You said it was from shields.io to badges.github.io, but I assume it was to badges.github.io/shields somehow; badges.github.io doesn't contain the same content).

Also, like you said, shields/master has an old history. However, it has a number of important design-level issues opened. If I understand correctly, master is pointless nowadays. On the other hand, gh-pages is used as the target of the ALIAS for the website; which I argue isn't as convenient and is particularly hard to guess for outsiders.

I wish to keep the git history attached to this project for many reasons, an important one being that I have a few experimental branches that I don't want to lose. Since we can't make shields/master start over (we'd lose the issues attached to it), we'd have to copy and paste the project on top of the current git history, and I'd lose gh-badges' history (and my branches).

Would renaming the current repo from gh-badges to shields-api be satisfactory?

[chadwhitacre]

I wrongly assumed that the reason you disliked shields.io redirecting to http://badges.github.io/gh-badges/ (instead of http://badges.github.io/shields/) was so that we would redirect to something that had a "shields" in the URL. Since that wasn't the reason, I'm not sure what was.

That was the reason, but (I think?) we were talking past each other, because I didn't think that http://shields.io/ was redirecting at all (DNS was misconfigured). I don't think http://shields.io/ should redirect anywhere. I think that should be our project's homepage. :-)

Also, like you said, shields/master has an old history. However, it has a number of important design-level issues opened. [...] Since we can't make shields/master start over (we'd lose the issues attached to it)

It sounds like you're conflating the shields repository, which holds the issues, and a branch, shields/master. The design-level issues are attached to the repo, not the branch.

I wish to keep the git history attached to this project for many reasons,

Sure, fair enough. I've brought over gh-badges/master as shields/master, with history intact. The old master branch is now at shields/old-master. Here's (roughly) the steps I followed:

$ cd shields
$ git checkout master
$ git branch old-master
$ git push --set-upstream origin old-master
$ git checkout --orphan master
$ git remote add gh-badges git@github.com:badges/gh-badges.git
$ git fetch gh-badges
$ git merge gh-badges/master
$ git push master --force --set-upstream origin master 

Next step is to do a merge from old-master to master, to address the files mentioned at badges/shields#117 (comment) ff.

an important one being that I have a few experimental branches that I don't want to lose.

I was unable to find any experimental branches in the gh-badges repo. The only two I see are gh-pages, and single-color. The former is obsolete in favor of the gh-pages branch in this repo (if there's history in gh-badges/gh-pages that we need to keep, let me know). The latter is an ancestor of gh-badges/master; it doesn't have any unmerged work on it.

What am I missing?

[chadwhitacre]

On the other hand, gh-pages is used as the target of the ALIAS for the website; which I argue isn't as convenient and is particularly hard to guess for outsiders.

It's odd to hear you say that, since that's how you've been doing it on gh-badges, no? :-)

If http://shields.io can do an ALIAS on an apex domain, the target is irrelevant; we can pick whichever is easiest. (You said it was from shields.io to badges.github.io, but I assume it was to badges.github.io/shields somehow;

We can't target badges.github.io/shields directly in DNS. That's what @olivierlacan tried to do with the URL record, which is how we ended up in this little mess with the 301 Moved Permanently redirect. That's actually a bit of a WTF, because URL paths like /shields are just not part of a domain name at all. No: we can only route to badges.github.io in DNS, with an ALIAS record, which is like a CNAME: it resolves to whatever the target resolves to. So in our case we resolve shields.io to whatever badges.github.io resolves to. badges.github.io is itself a CNAME to github.map.fastly.net, which resolves to 199.27.76.133, the IP address for GitHub pages that we saw above:

$ dig badges.github.io

; <<>> DiG 9.8.5-P1 <<>> badges.github.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5929
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;badges.github.io.              IN      A

;; ANSWER SECTION:
badges.github.io.       3600    IN      CNAME   github.map.fastly.net.
github.map.fastly.net.  30      IN      A       199.27.76.133

;; Query time: 65 msec
;; SERVER: 75.75.76.76#53(75.75.76.76)
;; WHEN: Tue Feb 18 20:21:58 EST 2014
;; MSG SIZE  rcvd: 85

$

Once we're inside GitHub pages, GitHub uses the Host HTTP header (presumably) to further route requests. Per GitHub convention, HTTP requests that come in for shields.io get sent to—ready for this?—whatever gh-pages branch of a project under the badges organization has a file named CNAME with the content shields.io. Namely, shields (I checked the rest of the projects under the badges org; two have gh-pages branches, but neither of those has a CNAME file).

badges.github.io doesn't contain the same content

Right! So ... by convention, GitHub routes HTTP requests with a Host header of badges.github.io to—ready again? :-) —the master branch of the repo named badges.github.io in the badges organization. That's @Mikulas' original project, before he graciously invited the rest of us to also use the badges organization (badges/shields#88 (comment)). :-)

[chadwhitacre]

@espadrine tl;dr shields/master now has all of your history on it, so you can pick right up where you left off.

Next steps as I see them:

• Merge shields/old-master to shields/master, to bring back content from the old README especially.
• Close this ticket.
• Migrate the remaining eight tickets from the gh-badges repo to the shields (with notifications to the six others involved besides you and I).
• Retire the gh-badges repo.

[espadrine]

Ok, so we can replace the git history of a GitHub project without losing the issues. I somehow assumed that wasn't possible. I now know about git checkout --orphan. Sorry for that. I too agree that switching is the way to go.

From what I understand, I must be careful to copy the CNAME file from gh-pages in the shields repo.

As for the README, what would you like to add from the old README? I'll happily add anything.

On the other hand, gh-pages is used as the target of the ALIAS for the website; which I argue isn't as convenient and is particularly hard to guess for outsiders.

It's odd to hear you say that, since that's how you've been doing it on gh-badges, no? :-)

I meant that when the master and gh-pages branches don't match, contributors don't necessarily find the website code easily.

[chadwhitacre]

I too agree that switching is the way to go.

Yay! :-)

I meant that when the master and gh-pages branches don't match, contributors don't necessarily find the website code easily.

Why? The point of the gh-pages branch is to hold static files for GitHub pages. I think most people know that, or can easily learn.

From what I understand, I must be careful to copy the CNAME file from gh-pages in the shields repo.

It sounds like you're thinking that we need the exact same files in both master and gh-pages. I don't think that's the way to go. I think master should contain the source for the API server at http://img.shields.io/, and gh-pages should contain static files for http://shields.io/. I think it's fine to automate an update to gh-pages based on changes to master. As we ramp up the design and marketing effort, I expect gh-pages to take on a life of its own.

[espadrine]

It sounds like you're thinking that we need the exact same files in both master and gh-pages.

That's exactly right, and I'd like to convince you. Not only does it ensure that the website is always up-to-date, it also makes updating it effortless. Contributors don't have to create a separate pull request and switch over to a different branch just to start working on the website. Moreover, testing the website and checking the badges against the website is much easier if the server API and the website can coexist in the same directory. In short, I see a lot of pros, and I don't see any cons.

I won't add that git branches were designed and implemented for merging. Or maybe I will.

[chadwhitacre]

As for the README, what would you like to add from the old README? I'll happily add anything.

I've done a merge in f0249e35019dac3a49621b6e1691d46bf8afe291. I moved the design spec and install instructions to separate documents, and folded the rest of the content together in the README. The "Retina-Ready" section needs to be rewritten.

[chadwhitacre]

I have a call, bbiab.

[chadwhitacre]

:-)

[espadrine]

Hmm, I thought you meant "We would need to discuss how to merge the READMEs", not "I'll add all the 116 commits from the old history". There's a lot of commits about files that don't exist anymore (and a lot of those files, too), including many binary files that I can't even read. There is a directory named "font" containing a single directory named "Open_Sans" which contains no less than 10 actual TTF fonts, none of which we use currently! And I doubt we'll ever use OpenSans-ExtraBoldItalic.ttf. The repo size rose from a slim 544K to a flabbergasting 5.5M of history! That's more than 10x!

Don't get me wrong, I love the added contributors, but I doubt it will make them want to work on the new codebase. And the log history looks like a cat's head glued onto a dog's body. Until that huge merge commit, browsing the history requires you to remember that it is made of two separate branches that have absolutely nothing in common, from the root down. That's too bad, because the only point of merging two branches is to have a clear history showing the incremental changes to the code.

As it turns out, I also have a local experimental branch containing a font/ directory, and that branch is the one about the ability to use Open Sans (or any other font), and it has a different layout. It isn't a big issue, but the sum of all those issues forces me to spend more time about meta things than about the project itself, and that saddens me, because this is my leisure time.

I'll list the changes that I'd happily have as a new commit on top of the gh-badges history.

• The README you manufactured is ok, although "Services using Shields" is a severe misnomer, and "Solution" is completely out of date and therefore misleading. The same goes for "Retina Ready", "Font" and "How to resize a badge".
• The CONTRIBUTING, INSTALL and LICENSE files are ok.
• The SPECIFICATION file should probably be put in a specification directory, along with design documents, although I'd rather we separated it into a different repo, or better, a wiki.
• We can safely keep the font and static directories out. They are not part of the code, they are out of date, and (in the case of font) they have no functional purpose.

If you agree, I'll do it.

[chadwhitacre]

If you agree, I'll do it.

I agree! Sorry for the noise. So you'll do a force push to master, then?

Eventually I see the content in SPECIFICATION ending up on a page under http://shields.io/ (however we decide to structure that). Maybe move it to an html page right now?

[chadwhitacre]

"Services using Shields" is a severe misnomer

Why is that? These are services that @olivierlacan et al. talked to and "sold" Shields to. They are the ones who have made a decision to follow the Shields design standard.

[espadrine]

Ah. Should I defined "Shields" as a specification for how badges look?

[chadwhitacre]

I won't add that git branches were designed and implemented for merging. Or maybe I will.

And users of technology are not allowed to find their own uses for it? ;-) Using the gh-pages branch to hold a completely separate file tree from master is a design decision made by GitHub Pages. The fact that git checkout has an --orphan switch indicates that this sort of usage is not totally unintended.

I don't like the idea of having one codebase for both master and gh-pages, because I expect different people to be working on them. So far we've been planning to use Jekyll in gh-pages (see badges/shields#91). Jekyll has its own filesystem layout that would be unnatural to fold together with the Node project layout we've got on master. The designers that we want to have working on http://shields.io/ don't need to be bothered with the guts of the API implementation, and vice versa. I agree there should be some automation in terms of documenting what services are implemented, but I don't think we can get away with having a single file structure in the long run.

[chadwhitacre]

Should I defined "Shields" as a specification for how badges look?

Shields is "a legible & concise status badge solution for third-party codebase services." In another context we defined the mission of Shields as "providing user-friendly metadata about open-source projects." The badge specification is one part of that, but Shields is bigger than just the badge specification.

[chadwhitacre]

I don't like the idea of having one codebase for both master and gh-pages

That said, having them in the same repo is good because then there's only one place for tickets, which helps newcomers (no, "Which repo do I ticket this in?"), and also encourages designers and developers to collaborate together.

[chadwhitacre]

@espadrine On the other hand, our experience with @opencompany has taught us that managing static files directly in gh-pages only works for the simplest sites. For example, with OpenCompany.org we wanted to implement translations, but GitHub doesn't run Jekyll plugins, so to use an i18n plugin we had to end up doing the build step ourselves. The solution we arrived at was to use one repo for the source, and a Travis-based build pipeline to place the built site files in a second repo.

We could do something similar here:

• use one repo for the API (this one? or go back to gh-badges, perhaps renaming it?)
• use a second repo for the source for http://shields.io/ (this one? or a new one called shields.io?)
• use a third repo for the built site; badges.github.io would make the most sense, per GitHub pages convention.

All of this is a bit out of scope for this ticket, though. Are we agreed that http://img.shields.io/ should redirect to http://shields.io/, however we end up organizing the code for each under the hood?

[espadrine]

Closing this, as the move is done now.