fixed typo

[andriijas]

This changes everything. Commander Keen reinvented! ;)

[mreeves1]

+1

[Soviut]

If you don't want contributions just say so ;)

On Wednesday, September 17, 2014, Michael Reeves notifications@github.com wrote:

+1

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-55957129.

[Blzut3]

Like most open source releases this repository is probably going to remain in the vanilla state. I can't say this is set in stone yet though, so that's why I haven't closed this request.

[keendreams]

I dont see why not have contributions. Soviut seems like he means well and wants to help. :)

[drdanick]

If you're accepting it, perhaps add a branch or some tags so we can differentiate contributions from the original codebase?

[Soviut]

All you have to do is hit accept. The merge will be automatic. I doubt you'll see any conflict on a typo fix in a comment. Just keep in mind that good documentation is king.

On Wednesday, September 17, 2014, keendreams notifications@github.com wrote:

I dont see why not have contributions. Soviut seems like he means well and wants to help. :)

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-55988477.

[Blzut3]

Javier (keendreams), regardless of your status as copyright holder, people are going to be more interested in the code as written by id than any official modifications. So if we end up working with a community maintained fork, we might be better off leaving this repository as is. If that plan falls through then we can determine what the scope of the project is and start accepting contributions. Obviously if we do this we'd want to keep a clear marking of the current head as drdanick suggests.

[keendreams]

Ok Blzut3, sounds reasonable. Perhaps a fork is in order?

[drdanick]

I agree. If people want to be contributing to this, it's more appropriate to be done on a fork, perhaps on another account to avoid confusion with the original source.

[Soviut]

This is ridiculous. Sorry I spent any time. Fork and fix, you have the diff.

On Wednesday, September 17, 2014, drdanick notifications@github.com wrote:

I agree. If people want to be contributing to this, it's more appropriate to be done on a fork, perhaps on another account to avoid confusion with the original source.

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-55991653.

[drdanick]

Don't apologize, I'm sure we all would want to welcome contributions! :) We just need to sort out where they would go.

[Soviut]

If it changed how the code ran I could see some concern. However, the whole point of a repo is anyone can go back in time through the commits. This isn't an archive, it's a living code base. Tag the original and start accepting contribs.

On Wednesday, September 17, 2014, Ian Zamojc izamojc@zamtools.com wrote:

This is ridiculous. Sorry I spent any time. Fork and fix, you have the diff.

On Wednesday, September 17, 2014, drdanick <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

I agree. If people want to be contributing to this, it's more appropriate to be done on a fork, perhaps on another account to avoid confusion with the original source.

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-55991653.

[keendreams]

I think Soviut has a point. A typo doesnt change the code itself. What do you think Braden?

[Soviut]

If you don't accept this I'll run the whole repo though spell check!

On Thursday, September 18, 2014, keendreams notifications@github.com wrote:

I think Soviut has a point. A typo doesnt change the code itself. What do you think Braden?

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-55993389.

[keendreams]

Soviut, i bet you'd find lots of f-bombs there if you do! :D Like its been said, i more than welcome contributions, Im just trying to make sure whats the best way to add them. This is the first time I add source code to github. Im new to github.

[Blzut3]

Javier, as I said before. Once we figure out what path we're taking for sure then we'll decide what to do. it doesn't make sense to decide that now regardless of how harmless it may be.

Sovlut, go right ahead. :P I do understand your point, but we wouldn't be the first archive repository by a long shot. For example, I believe id software has only ever accepted one fix. It is completely normal for these kind of repos to be launching points. Now I must definitely emphasize that we are still working out some details at the moment (I'm trying to get in contact with at least one of the existing forks). So hang tight. Javier making a fork of his own repository would definitely be pointless, so either we will be leaving this repository untouched or setting a goal and working towards it. We are not in a position right now to make this decision.

[Soviut]

It's a repo, not an archive; You can tag, fork, rebase or revert from any point in history. Accepting a pull request on a typo fix isn't polluting anything. There's always recourse should you feel that this fix violates any purity laws. There is always a way to get back to a pristine state, that's the whole point of version control. Why not keep the OLD code in a fork called "classic" and let the community send pull requests?

I had no idea a one word typo fix would insight this much discussion from the council of wizards.

[andriijas]

Chill guys. They just put the code up the other day. Let them sort out how they want to handle stuff first. Amazingly enough all this debate regarding a typo. Not some new crazy cheat code.

[drdanick]

Just remember that this is historical code, not current and maintained code. Even though its not a significant change, it's probably good if everyone discusses how this is going to work before someone tries to PR any drastic changes (such as porting the 16bit asm to 32bit). Seriously though Soviut, don't worry about it, none of this has anything specifically to do with your PR. This is the first PR made, and the fine details around it just need to be sorted before any are accepted. Don't let it stop you from looking for other things you'd like to change :)

[Soviut]

Deal with it the way all historical code is dealt with in a version controlled repository; Tag it or fork it, but keep the mainline/master clear for contributions. Nobody keeps their master branch as the "historical" branch, that's where changes and latest versions are assumed to be happening. Tag or fork as "classic" or "original" and you're done.

[drdanick]

Yeah, that's all fair. But it's probably just best to let the maintainers meet and discuss this as a simple matter of protocol. Honestly, I don't even think they were expecting to get any PRs :P

[Soviut]

@drdanick Community contributions and pull requests are one of the fundamental aspects of Github. I hope this (regardless of how small a contribution it is) makes the owners realize that this is a repository, not an archive. It's a workshop, not a museum. There are dozens of ways to properly identify the original source and dozens more ways of returning the repo to a specific historical state. However, in all cases, the master branch should not be where the original pristine source lives.

[drewnoakes]

@Soviut, GitHub gives control over the repo to the owner and any contributors they elect. It's designed to let others make modifications to their heart's content in their own forks and propose these to the owner who may accept or reject for whatever reason they like. If a repo owner fails to update a project in a way that the community disagrees with, then the community moves to a fork. This happens regularly in practice, though normally when a significant set of changes are produced, and only when enough people appreciate said changes.

As an aside, what I would be interested in seeing in another branch or fork is some additional commentary about the code. There's a lot of context to this code around the systems of the time (CPU, memory architecture, OS) which isn't self-evident in the code directly unless you were writing this kind of software back then. This code is fascinating, but I feel there's a lot of stories and information lying just out of (my) reach within.

[Blzut3]

Soviut, I can come up with a number of reasons to archive here instead of in a 7z.

• Exposure. Code on GitHub will be easier to find and easier to reference in discussions than an archive on some obscure website.
• We released the code for every version. A repository allows the diff to be seen easily.
• There is a social aspect, as now you can fork the repository and your fork will show up in a list. Just look at how many people are porting the game already!

Tag or fork as "classic" or "original" and you're done.

If we choose to do nothing, this would be the "classic" or "original" fork. So what if it's a root. You can follow the network graph to find maintained versions. ;) (Note nothing is decided yet, I haven't gotten a response from the person I'm trying to get a hold of.)

[ryantheleach]

Just make a fork, git is dangerous enough as it is without someone force pushing to this repo at a later date and permanently ruining this.

[Blzut3]

Who said anything about force pushing?

[Soviut]

This is the most ridiculous discussion I've ever seen on GitHub. If you post it here, expect contributions; especially with a name attached to it and being posted around twitter where I found it.

It's a typo fix and suddenly the purity zealots wake up, descend, and declare it an immovable object. you want to know why people give up on open source? It's this. Optimists who post some source with no intention of maintaining the repo.

Either act or let it die! Holy hell, this is simple but you're lack of action speaks volumes about your intent with the aforementioned source. Clearly it's meant to collect dust!

Take if to some obscure ftp! It's only fitting.

On Saturday, September 20, 2014, Braden Obrzut notifications@github.com wrote:

Who said anything about force pushing?

— Reply to this email directly or view it on GitHub https://github.com/keendreams/keen/pull/1#issuecomment-56256805.

[Blzut3]

@Soviut really? Commercial software not accepting pull requests is why people give up on open source? Is that why Doom source ports aren't updated? Again, I refer you to all of the id software repositories which don't take pull requests and are serving their purpose just fine.

As I said before, posting on GitHub is more of a service for those developing source ports. By looking at the network graph I can easily tell there are 3 source ports being developed right now. If we uploaded to some ftp server you would not be able to see that, why is that so hard for you to understand?

Secondly, you are starting to get a bit insulting with your continual suggestion that I don't know how DVCS works. I shall inform you that I maintain and contribute to a number of source ports (some on Bitbucket), and these are projects which do get and accept pull requests on a regular basis.

[drewnoakes]

Further to @Blzut3's comment, consider the case of the GitHub repo for Git itself! It doesn't accept PRs and is only used as a mirror. The owner elected another method to manage the source code, and the community has to accept that.

Let's not bring any negative attitudes to the release of this historic code base. It's really great that the copyright holders agreed to open source it. Thanks very much to all involved.

[Blzut3]

I've made contact with sulix, who started working on his port in much the same way I would have started, so development will happen there. If you wish, you may submit the pull request to him. I believe one of the other forks incorporated the change already, although I don't recall which one off hand.

[Soviut]

@Blzut3 It would have been nice to confirm this before closing the branch. I don't know where to resubmit to. You told me a name I don't recognize and provided me no links or direction.

[Blzut3]

I don't know why, but I wasn't expecting GitHub to just close when I clicked the button. (On Bitbucket it prompts for a comment so I guess I'm just used to that.)

Here's a link: https://github.com/sulix/keen-dreams-sdl2

[Soviut]

Ah. There's a "close and comment" button but it will still close it with a message.