Posts by selurgniman

Quote from Two

There are 3 main branches:
- Experimental: This is where Alblaka (and maybe others) pur in their ideas/major code changes, the "What if?" branch. Only requirement: game must still be playable, as in "doesn't crash too often". Bug-fixes may happen but are not required.
- Development: One a feature or set of features has been accepted, it is put into the development branch. Here all bug-fixes happen and ideas/code might get improved or slightly modified (under the control of Alblaka) with the target to have a fully releasable version in the end. Requirement for all commits is to be compilable and fix bugs/improve code without introducing new bugs.
- Release: Once a development branch has been stabilized enough, it is branched out to a specific release version branch. Once this is done that version is considered released and only bug-fixes that address stability issues may happen to this branch. New features or improvements of existing features do not belong here. There is a minimum delay of 1 month per release, so not every minor change caused server admins the trouble to update.

Actually this isn't the way you should use git, you have a "master" branch which serves as your trunk (ie, all branches merge back here and all releases live here). When you wanna work on something you, as the developer check out your own copy of the repo and work on your code and then submit a pull request when you're done. The project owner (or his delegates) then have to accept the pull requests and handle any merge conflicts. When the project owner is ready to do a release, they "tag" those files in the master branch with a version number which can then be used to que jenkins or whatever build system you're doing to generate a "recommended build".

The key there is that you tag releases, not branch them. You can roll your repo back to tags just like branches but not have to deal with all of the ugly branching :).

Quote from Two

- There should be a standardized way of submitting bugs/requests. The primary focus here is ease of use as I expect more non-technical feedback than actual coders to use it. This doesn't have to be a highly sophisticated tracking tool, even the forum could be a solution, just something that works fine for the task.

Github has a built in issue tracker.

Quote from enneract

if IC2 goes open source, I eagerly await the ability to contribute.

Agreed.

Quote from Drizak

Thanks
Perfect sum of my thoughts when listening to the video.
Please do the regular builds, and accept help from the users, the bug tracker is one of the most coolest ideas, but if the dev-team is not going to make hotfixes (or regular builds, w/e) it will not be useful, i mean, what he says on the video is true, we' been waiting almost 3 weeks to get a bugfix, and got no answer until this.
Please, take advantage of this situation and reconsider some things =)

Completely disagree. Even if he doesn't change anything else about the IC2 development process; at least you could see known issues as well as possible workarounds and acknowledgements by the devs.

Quote from imer

In addition to that it's been getting quiet around here.
I don't know the devs opinion on this, but in my opinion an active community is a very important motivation-booster.
I mean back in IC1 days everyone would have spammed a thread with "leaked blueprints" for a new reactor system (bad example here ).
And don't get me wrong: we don't have a bad community here, but it's getting quieter and (i assume) most people are only here to look for stuff and then go away again.
Pageviews have been decreasing too, we once had 300-350k on one day, now it's always around 100-150k (on weekends ~200k)
The bounce rate has been going up, too (user leaves website after one visit)
Dont hate me for this, but modpacks proably are the biggest reason for this: why would you need to visit ic.net?
They have their own (mostly copied) wikis, that include hidden recipies, and a larger community in their forums.

Display More

Actually I would say the view count has been dropping due to the pace of development. Here we are over two months later with no 1.3.2 compatible build and 1.4 probably only a couple weeks away. Shortly after 1.3.0 dropped I was checking the site and forums multiple times per day for updates, then once per day, then only when my RSS feed of the main site updated, now only when something interesting pops up in the RSS feed.

I think a lot of people are used to mods just being abandoned in MC and so have become more apt to just move on once it appears evident that the mod is no longer going to be updated. For example, most of my players are in favor of moving on without EE3 because it's obvious that that mod is probably not ever going anywhere. I wrote up a little forge mod to replace the easy bits and we're moving on without EE3. IC2 would be harder to move on from but not impossible, eventually the features from the game updates are going to be compelling enough.

Obviously you have your reasons for keeping it closed source but what about exposing an RSS feed or something from your SCM or build system? That way, we'd at least see that stuff's happening and it wouldn't be dependent on you having to pull yourself away from what you want to be doing to assemble a status post.

Another idea might be to assemble a closed beta community with access to an issue tracker. They could get earlier access to the builds to file issues and you wouldn't have to worry about the forums being flooded with complaints.