Fix os.Error rename to error builtin

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download the latest version (d3774ec05810 tip) using goinstall+gopath
2. Try to compile the package
3. See the error

What is the expected output? What do you see instead?
The system should compile without any problems.

The system show many messages of errors in the mux.go file. Running the latest 
gofix on those make the changes and the compilation runs without any problmens.

Please provide any additional information below.

Go version: 780c85032b17 weekly/weekly.2011-11-02

I will not place the pathc file below since just running gofix mux.go and gofix 
mux_test.go fix the problem.

Original issue reported on code.google.com by andrebq on 4 Nov 2011 at 2:20

[GoogleCodeExporter]

The repository is not intended to be in sync with latest weekly, so this is 
expected. Fixing that, we would break those who use it with Go r60. So that 
would need a separated branch just for the weekly. Am I missing something?

Original comment by rodrigo.moraes on 4 Nov 2011 at 9:44

[GoogleCodeExporter]

I think having a branch (or a tag) for a release is even better. Some of us 
(like me) would like to keep up-to-date with the latest version be it be a beta 
or weekly.  This also makes everything consistent. There are few other popular 
packages out there (like https://github.com/nsf/gocode.git) and 
(https://github.com/skelterjohn/go-gb.git) where the master branch is always 
up-to-date with the latest weekly version (and some extra). Each weekly and 
release version can be tagged so that anyone who needs the stable version or 
older weekly versions can switch to tag/branch and install it. I think this 
will keep the frustrations level of new users down. Honestly, I struggle a lot 
trying to update one or other package because of different packages maintaining 
their repos differently.

I would have helped managing the project like tagging, branching, merging pulls 
etc (if you wish) but I'm only good at git but not at hg. So, here is another 
embedded question - any chance of hosting all these on github?

Original comment by ashokgelal on 4 Nov 2011 at 10:21

[GoogleCodeExporter]

I think this is a ideal, but for me it is a maintenance hell. I can't guarantee 
I'll be able to maintain it in sync with weekly, so currently it only targets 
stable release (r60.3 right now).

If you would like to maintain a weekly branch, I can give you commit rights, or 
I can follow a clone and pull your changes.

Original comment by rodrigo.moraes on 4 Nov 2011 at 11:27

[GoogleCodeExporter]

Re: git. I created a mirror:

https://github.com/moraes/gorilla

You can just use git, and I'll use hg-git to pull. Main repo remains googlecode 
one.

Original comment by rodrigo.moraes on 5 Nov 2011 at 12:57

[GoogleCodeExporter]

You are super awesome! That's great! I will try my best to keep the repo 
updated (infact, I already did on my local machine). Now only you can give me 
the rights to push.

Original comment by ashokgelal on 5 Nov 2011 at 1:32

[GoogleCodeExporter]

Oh. Wouldn't it be better if you just cloned it, then I pull your changes?

Original comment by rodrigo.moraes on 5 Nov 2011 at 7:07

[GoogleCodeExporter]

By "cloned" i mean "forked". ;)

Original comment by rodrigo.moraes on 5 Nov 2011 at 7:08

[GoogleCodeExporter]

That works too! I thought that would be more maintenance work for you.

Original comment by ashokgelal on 5 Nov 2011 at 4:28

[GoogleCodeExporter]

This issue was closed by revision 091589b782b4.

Original comment by rodrigo.moraes on 6 Nov 2011 at 10:53

• Changed state: Fixed

[GoogleCodeExporter]

Sorry for the mess of commits. 

The weekly is now available in 
http://code.google.com/p/gorilla/source/browse/?name=go.weekly.2011-11-02

I don't know how to keep git in sync with branches. Because now repo on github 
is in sync with the hg one, but the weekly branch doesn't show up. 

I am not an expert in these things. Not fun.

Original comment by rodrigo.moraes on 6 Nov 2011 at 11:25

[GoogleCodeExporter]

Now some ramblings.

With Go 1 around of the corner in a matter of months, I really don't want to 
maintain compatibility with weekly. It is hard to have to worry about new 
features implemented and tested in the stable version *and* a moving target.

To make things worse, gorilla must be compatible with App Engine, which 
sometimes is even a few stable versions behind.

So my approach is: when a stable Go is out, move there and wait for next 
stable. Hopefully Go 1 will make this situation better.

Original comment by rodrigo.moraes on 6 Nov 2011 at 11:46

[GoogleCodeExporter]

I can totally feel your pain. Maintaining a moving target is really pain. But 
on the positive note, this also helps testing all the gorilla projects as we 
move along so that when Go 1 comes, we will be ready on the first day. If I 
were you, I would keep everything on code.google.com main branch in sync with 
the release and leave github so that it has the weekly and other experimental 
branches. With these, those who need stable branches don't have to do anything 
else but for those who need the latest *experimental* features can take a 
little bit pain and download the relevant tag/branch from github (and hopefully 
report us with any issue/bugs/improvements). There are other advantages of this 
approach:
1. gorilla can keep both parties happy and have more users.
2. Nothing needs to be touched on the main hosting (code.google.com)
3. Any experimental features can be implemented and then revoked
4. More contributors, more bug fixes, more updates, more activities = good 
symptom for an open source project = more words out there about this awesome 
toolkit.
5. No more people filing issues for gorilla not being supported for the latest 
weekly release. We can just point to github and say "all the weekly branches 
are not officially supported and might only work partially. Some tests might 
not even pass. Use at your own risk".

Again, I understand the impact of this. Rather than concentrating on new 
features and main issues, we will be allocating a piece of our time and efforts 
to something that changes every week. But there are also some advantages. As a 
project creator and maintainer, the final decision is yours.

My 2 cents. Sorry, if you feel that I'm trying to cross too much on you and 
this project. It's just that I love this project (any open source project 
overall but gorilla is super awesome). 

Original comment by ashokgelal on 7 Nov 2011 at 12:58

[GoogleCodeExporter]

I really appreciate the help of you guys. :)

I'm just ranting because I'm worried I won't be able to keep two versions. I'd 
like to, but it is a waste of time and sanity. :P And this is not even a big 
project. Go 1 was planned because this situation is impossible to sustain.

That said, I love that you want to push weekly compatibility. I've added you as 
collaborator on github. Please let me know if this is sufficient. Do whatever 
is needed on github, and I'll link that project as the bleeding edge for 
weeklies.

:)

Original comment by rodrigo.moraes on 7 Nov 2011 at 10:53