Near Infinity future development

[Taimon]

I'm still opposed to the bump in requirements (it especially sets the bar way too high for Mac OS X support), but it's not like I'd be involved anyway.

I'm not really happy with my changes there and I'll probably revise them someday.

 

But apparently, I've too much stuff on my hands to implement things properly now.

[Taimon]

But we want to have just one perfect version, don't we? I mean if there is four forks with four devs, it would be complete mess, wouldn't it?

 

What I'm trying to say is, that there is no dependency on one person as a maintainer. Everyone can take over.

 

Besides, if you don't like a specific feature (e.g. JRE version bump) you don't have to include it in your version.

[the bigg]

I mean if there is four forks with four devs, it would be complete mess, wouldn't it?

No. The way git works is that, while everybody has access to a full repository in read/write mode, one of those is chosen to be the master and thus used for publishing purposes, while the other devs will sync their repository to the master, change the source, and then send their diffs to the master.

 

http://en.wikipedia.org/wiki/Git_%28software%29

[devSin]

The sources I have online were updated a week or two ago and have some fair changes over the build I originally gave you, so you may want to look over those and see if it'll be easy to merge before setting up the git; the changes I have locally are all minor, so you don't really need to wait for them--and it totally saves me having to feel bad when I fail to even touch the sources until next year, after claiming I'd do it in the next day or two. :-)

 

I can't remember how far back, but it's probable I gave you some really stupid bugs that would be embarrassing in the public repository! Optionally, you can also add a TODO list and stick native ACM handling at the top. ;-)

[Taimon]

so you may want to look over those and see if it'll be easy to merge before setting up the git;

I'll set git up locally and then do the merge before pushing it to github.

(Someone has to motivate me for the merge, though. )

 

and it totally saves me having to feel bad when I fail to even touch the sources until next year, after claiming I'd do it in the next day or two. :-)

I know exactly what you mean. Well, probably any developer knows.

 

[...] but it's probable I gave you some really stupid bugs that would be embarrassing in the public repository!

Since NI code is not that ... ehh ... clean, nobody would really notice it anyway.

[drake127]

I mean if there is four forks with four devs, it would be complete mess, wouldn't it?

No. The way git works is that, while everybody has access to a full repository in read/write mode, one of those is chosen to be the master and thus used for publishing purposes, while the other devs will sync their repository to the master, change the source, and then send their diffs to the master.

 

http://en.wikipedia.org/wiki/Git_%28software%29

Thanks for explanation, I have experience mainly with subversion approach which has centralized repository, yet all other developers may contribute directly to it and everyone's equal. I guess it is a bit less safe but much better when master developer has no time to approve diffs (or get hit by low flying airplane). Or I may have understood it wrong in which case feel free to ignore this paragraph. I'll look at it again in more depth later.

 

Back to NI though, do I understand correctly that I can look forward to new shiny version of NI that will be placed in repository with diffs and author notes and a lot of fancy buttons etc. And that there will be new official branch (trunk) which will be considered official. And if someone (for example me) would like to add new feature, he would just commit diff to this trunk.

 

Currently developers are not tied to one maintainer as well but it means devSin's, Taimon's, Kung Fu Man's, mine and SourceForge's forks and it *is* a mess. And that's why latest version is probably still 1.33 Beta 19 since there is no official successor - and not necessarily person, one team repository would be even better. I suppose there will always be means to grant access to new developers when someone wants to leave.

[the bigg]

Thanks for explanation, I have experience mainly with subversion approach which has centralized repository, yet all other developers may contribute directly to it and everyone's equal. I guess it is a bit less safe but much better when master developer has no time to approve diffs (or get hit by low flying airplane). Or I may have understood it wrong in which case feel free to ignore this paragraph. I'll look at it again in more depth later.

There's nothing in my WeiDU repository that makes it a master over Taimon's. In the event that I snuff it, Taimon will simply announce to everybody that he is the maintainer; after that happens, everybody will simply pull from/push to Taimon's tree rather than mine, and Taimon will publish new WeiDU versions from his tree.

[Taimon]

Back to NI though, do I understand correctly that I can look forward to new shiny version of NI that will be placed in repository with diffs and author notes and a lot of fancy buttons etc.

Nothing shiny and no notes, diffs or whatever. Just what I have and probably the merge of devSin's version.

 

I suppose there will always be means to grant access to new developers when someone wants to leave.

That's not how it works. You will have your own (complete) "fork" where you update things and pull changes from other developers. It takes a while to get familiar with it, after you used something like CVS or Subversion, but it's a much better model for open source software development.

 

For now, I'm only putting the source code in the repo. We still need to think about binary release management, but first things first.

 

There's nothing in my WeiDU repository that makes it a master over Taimon's.

Perfect explanation.

(But don't even think about handing WeiDU over to someone else. )

[Guest i30817]

Java 1.6 is in the next Mac os update, so no need to be shy of it.

[drake127]

OK, I think I got it (watched http://www.youtube.com/watch?v=4XpnKHJAok8) and distributed SCM sounds at least worth the try. I still have some doubts about it but it would be off topic in this thread.

 

I know that I cannot expect diffs between "current" NI and 1.33 Beta 19 and they are not necessary (as long as new version is at least as stable as Jon's) but when it makes its way into repository, there are means to track and document changes and I believe they should be used.

 

So, let me know when there will be NI sources at git and we'll see how to make them official and whether we make some website or such. As you said, first things first.

[devSin]

Nothing shiny and no notes, diffs or whatever. Just what I have and probably the merge of devSin's version.

I did a quick Frankenmerge with my local copy this morning. Not really anything to write home about, though.

 

I changed slightly to not screw up the CHR format anymore for ID2 (it should be right in the GAM, according to Avenger, although it's mostly useless since I have no idea if IwdRef actually works so didn't use it, but is back to a run of unknowns in the CHR), but it'll still be stupid for other nonstandards (PST and maybe IWD). Sorry, folks.

[Taimon]

I did the merge today (with your version from yesterday). 4K diff.

Guess I'll have to do another one.

 

Still have to check if all compiles and it basically works.

[devSin]

There are just a few field changes, and the aforementioned changed to special case handling of ID2 CHRs, so it hopefully won't be too cumbersome. And maybe a final formatting change or two to again get as close to Jon's b19 as I can afford to waste time on.

 

I actually rejected most of the local changes, so it's definitely less of a beast than merging yours and yesterday's.

[Taimon]

Don't worry.

I'm keeping a local branch of your version -- merging should be relatively trivial from now on.

[Taimon]

Okay, source is on github.

 

I did only check that it compiles not if it works.