| 01:28.14 | *** join/#bzflag therealtbe (~AresHandl@pool-74-109-244-171.pitbpa.fios.verizon.net) |
| 01:30.41 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 02:04.32 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 02:39.25 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:ddc1:ca92:8c4f:393a) |
| 03:27.46 | Constitution | Flash: regarding https://github.com/BZFlag-Dev/bzflag-import-3/commit/f51ecae7aabf31a354b31b661d5debe6097fe479 |
| 03:28.19 | Constitution | I don't think we want 10.9 to be our deployment target? we haven't even formally discontinued 10.6 support |
| 03:30.26 | Constitution | and I may be wrong on this, but I don't think we want to make modifications to the src/other directory just to fix warnings? better to submit a patch upstream so our work isn't undone every time we upgrade to a later version? |
| 03:31.49 | Constitution | regarding the header guard in bzfsHTTPAPI.h? I have noticed that before, but I couldn't decide if it was intentional? might want to ask Patlabor221 |
| 03:46.28 | Patlabor | what did I mess up? |
| 03:47.36 | Patlabor | Constitution, really a 5 year old OS? |
| 03:48.18 | Patlabor | what's wrong with bzfHTTPAIP.h? |
| 03:48.38 | Patlabor | ahh I had plugin |
| 03:48.41 | Patlabor | yeah that's a good change |
| 03:49.19 | Patlabor | 10.9 is fine, if people want to use an older version they can use old bins |
| 03:50.39 | Patlabor | the odds of us building a 2.4.6 is very low |
| 04:16.15 | Constitution | for a 20 year old game, it seems very appropriate ;) |
| 04:19.02 | Constitution | more seriously, as long as the cost of supporting an older OS does not exceed a simple build setting, I see no reason not to support it |
| 04:19.51 | Constitution | 10.7 may be a good target for now, since that will allow us to use the later C library which is required for the c++11 features |
| 04:23.06 | Patlabor | can 10.7 even use the version of xcode we have? |
| 04:25.43 | Constitution | the xcode project file format hasn't changed since 10.6 iirc, so yes |
| 04:27.18 | Patlabor | seems silly to me |
| 04:27.32 | Patlabor | can a 10.7 user just change the build target and build? |
| 04:28.43 | Constitution | sure, but so can we, in the official build, to save them the trouble |
| 04:28.56 | Patlabor | what official build? we don't have one |
| 04:29.02 | Patlabor | if we do a bin, sure |
| 04:29.07 | Patlabor | but untill then, it's moot |
| 04:31.29 | Constitution | shouldn't the IDE project files be kept in a state as close as possible to what we need for a release? |
| 04:31.43 | Patlabor | meh |
| 04:31.54 | Constitution | or are you expecting us never to release another version again |
| 04:32.06 | Patlabor | you have to set build targets for official releases anyway |
| 04:32.21 | Patlabor | I say do what is easiest for new development, that is where it's lacking |
| 04:32.49 | Patlabor | when the time comes, we can change the build target, let him keep working :) |
| 04:33.29 | Patlabor | because honestly for the number we are talking about here, you are defending like 3 people |
| 04:34.59 | Constitution | and you would throw them out in order to gain no conceivable advantage? this build setting doesn't preclude development on later operating systems |
| 04:35.57 | Patlabor | I would not worry about the build target untill we have a build :) |
| 04:36.26 | Patlabor | if you don't like it, just change it |
| 04:36.32 | Patlabor | if the files are compatable it dosn't matter |
| 04:36.40 | Patlabor | but I'd not force flash to do it |
| 04:37.05 | Patlabor | but I would ask if the newer build target has any optimisations |
| 04:39.21 | Patlabor | if 10.7 truely does not offer any disadvantage and supports the same C++11 as our GCC target, then it's a fine build thing to set it to |
| 04:39.37 | Constitution | it's the same compiler? the setting just selects which API features are available |
| 04:39.46 | Patlabor | ok |
| 04:39.49 | Patlabor | then change it |
| 04:41.05 | Constitution | okay, but I was waiting to hear from Flash why he defined the setting in that commit |
| 04:41.16 | Patlabor | it was probably defaulted |
| 04:41.23 | Patlabor | make your commit comment clear and he'll understand |
| 04:41.41 | Patlabor | his commit comment was about compiler warnings, that settings does not seem to be about compiler warnings |
| 04:41.53 | Patlabor | if you change it and still get compiler warnings, fix the compiler warnings |
| 04:45.21 | zuii | hi |
| 04:45.36 | zuii | where is the bzflag sourcecode? github or still on svn? |
| 04:45.54 | Patlabor | github |
| 04:45.54 | zuii | sry for interrupt |
| 04:46.04 | zuii | 3.0? |
| 04:46.11 | Patlabor | there is no 3.0 |
| 04:47.30 | Patlabor | 2.4.2 is the last public release, there is 2.4.3 code that is compatabile with bug fixes |
| 04:48.39 | zuii | okay thank you |
| 04:48.43 | Patlabor | sure |
| 04:53.48 | Patlabor | just be sure to get the v2_4_x branch |
| 05:05.26 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 05:15.10 | zuii | i cloned like git clone -b v2_4_x https://github.com/BZFlag-Dev/bzflag-import-3.git bzflag_v2_4_x |
| 05:15.32 | Patlabor | thats the one |
| 05:17.46 | allejo | still thinks the v2_4_x branch should be the landing page on github instead of the "master" branch |
| 05:18.16 | Patlabor | you are correct |
| 05:18.56 | Patlabor | the game confuses people, so it must be traditoal for the repo to do so as well |
| 05:19.06 | allejo | the "master" branch isn't even being used correctly |
| 05:19.10 | allejo | lol |
| 05:20.10 | Patlabor | I'm not sure why we can't finish an import in a year :) |
| 05:20.23 | allejo | what's left to do? |
| 05:20.30 | Patlabor | no idea |
| 05:20.36 | allejo | anything i can help with? |
| 05:20.45 | allejo | oh |
| 05:20.48 | Patlabor | ask the import manager |
| 05:21.16 | allejo | BulletCatcher ^ |
| 05:21.59 | Patlabor | probalby some form of voodo |
| 05:22.05 | Patlabor | and mucking with the branches |
| 05:22.21 | allejo | gets his voodo doll of jeff ready |
| 05:22.46 | Patlabor | why do you have a doll of a slightly overweight white guy? |
| 05:23.26 | allejo | ...for voodo |
| 05:23.56 | Patlabor | rrrrrrrriiiiiiiiigggggggghhhhhhhhhtttttt |
| 05:24.04 | Patlabor | whatever turns your crank |
| 05:24.39 | allejo | thought the phrase "voodo doll" would suffice |
| 05:24.55 | Patlabor | techincaly you would need my hair |
| 05:25.04 | Patlabor | that's how Thaumaturgy works |
| 05:25.33 | zuii | or his toothbrush |
| 05:26.34 | Patlabor | possible but harder, less connection |
| 05:26.48 | zuii | Patlabor==JeffM ? |
| 05:27.01 | Patlabor | a vicious rumor |
| 05:27.07 | zuii | :) |
| 05:29.11 | allejo | has his ways for getting hair |
| 05:29.38 | Patlabor | there is less on the top of my head then there used to be |
| 05:29.41 | Patlabor | gettin old sucks |
| 05:29.45 | Patlabor | I don't recomend it |
| 05:30.06 | allejo | lol |
| 05:30.10 | allejo | so i've heard |
| 05:33.34 | BulletCatcher | Getting old is better than the alternative. |
| 05:33.55 | Patlabor | I dunno, cyborgs sound pretty cool |
| 05:35.05 | allejo | cartoons make them look cool |
| 05:36.27 | Patlabor | it's all about the whaffles |
| 05:38.09 | allejo | prefers french toast |
| 05:40.41 | allejo | or chocolate chip pancakes |
| 05:40.59 | zuii | hmm |
| 05:42.47 | BulletCatcher | Probably the biggest obstacle to producing a permanent Git repo is reaching a consensus on the branching model to use. |
| 05:42.50 | BulletCatcher | Several of us have some incompatible ideas, but I have come around to the conclusion that It Doesn't Matter Much, especially at the current rate of development. |
| 05:43.23 | Patlabor | Just pick one |
| 05:43.48 | BulletCatcher | If we can just agree which branch should be master, the rest will be inconsequential. |
| 05:44.08 | Patlabor | Shiping |
| 05:44.15 | allejo | I'd think that until 2.5.x development actually starts, 2.4 should be the master branch |
| 05:44.46 | Patlabor | the issue with that is development doens't realy have a "Start" |
| 05:44.53 | Patlabor | you have to ask what the goal of the repo is |
| 05:44.55 | zuii | whats your play for 2.5-2.6? every logic on server side? |
| 05:45.06 | Patlabor | zuii, nope |
| 05:45.09 | Patlabor | it has no real features |
| 05:45.26 | Patlabor | with our release rate the repo is mostly used by current players to get bug fixes |
| 05:45.30 | Patlabor | so shipping makes sense |
| 05:45.39 | Patlabor | it's the "Stable" code |
| 05:45.45 | Patlabor | and dev happens on a branch |
| 05:46.25 | allejo | "start" might not be the right word. when 2.5.x actually has a direction to head in, then the current master moves to a 2.4 branch and master becomes 2.5 |
| 05:46.26 | Patlabor | anything else has the same problem as now, "we have to tell less techicaly inclined people how to get a branch" |
| 05:46.40 | Patlabor | you want it easy for the people that know the least |
| 05:46.57 | Patlabor | making master incompatable will not help them |
| 05:47.10 | Patlabor | it only helps new devs, but they sould know already |
| 05:47.26 | Patlabor | I'd have master be shipping, and the active development be "Dev" or something |
| 05:47.40 | Patlabor | then we snap off named branches when we have stuff to release |
| 05:48.09 | Patlabor | main would become 2.4.3, and we'd rebase dev to main when 2.6 release |
| 05:48.09 | zuii | i agree master should be always stable |
| 05:48.19 | Patlabor | that way we arn't renaming branches all over the place |
| 05:48.42 | Patlabor | and if we decide to change a version number for active development, we can do that in dev branch and not rename it |
| 05:48.59 | Patlabor | but that's just my 0.0157 euros |
| 05:50.18 | allejo | so master for now will always have 2.4.x stable code and a proposed "dev" will be any 2.5.x changes? |
| 05:50.41 | Patlabor | untill dev is stable, then it'll be pushed to main |
| 05:50.47 | Patlabor | master or whatever |
| 05:50.51 | BulletCatcher | Right now we only need to name two branches. v2_4_x and v2_6_x are their names in the bzflag-import-3 repo. |
| 05:50.54 | Patlabor | master is the bug fixes for shipping |
| 05:51.00 | allejo | likes that |
| 05:51.11 | Patlabor | yeah it's all you need is 2 |
| 05:51.20 | Patlabor | I'd keep them with generic names like "master" and "dev" |
| 05:51.33 | Patlabor | and then if releases happen they get branchs with specific versions |
| 05:52.01 | Patlabor | so BulletCatcher can I just rename the import3 repo and it's branches? |
| 05:52.48 | allejo | and by specific versions, it'd be 2.x, not 2.x.x, right? because for 2.x.x releases it would be appropriate for them to be tags |
| 05:52.51 | BulletCatcher | No, I have some other changes pending. |
| 05:53.04 | Patlabor | allejo, they would not need X |
| 05:53.14 | Patlabor | since at the time of branch we'd know the revision number |
| 05:53.42 | Patlabor | so if we were to release 2.6, we'd first take master, make a 2.4.3 branch |
| 05:53.47 | Patlabor | so that codebase was saved |
| 05:53.50 | Patlabor | then push dev to master |
| 05:53.57 | Patlabor | and version it 2.6 |
| 05:54.09 | BulletCatcher | "push dev to master" isn't a thing in Git. |
| 05:54.12 | Patlabor | then dev would be versioned 2.6.1 for 2.6.x dev |
| 05:54.45 | Patlabor | I'm sure there is a way to rebase or merge a branch |
| 05:55.06 | Patlabor | dev would be a branch off master, so it should be able to be merged back in |
| 05:55.15 | Patlabor | if not then git sucks |
| 05:55.44 | allejo | a 2.4 branch instead of a 2.4.3 branch, right? because should some dev need to happen, it'd still be in the 2.4 branch |
| 05:57.05 | BulletCatcher | Merging the dev branch back onto master would be possible, but the only reason to do it would be to avoid having to rename the branches. |
| 05:57.33 | Patlabor | when dev becomes master, we are saying we are DONE with the old master, and have released 2.6 |
| 05:57.35 | Patlabor | so at that point nothing should go into 2.4.anything |
| 05:57.39 | allejo | merging two branches would need work out like a pull request where the history matches up, so to speak |
| 05:58.11 | Patlabor | sure, renames could work, I don't don't know how renames jack with hstory |
| 05:58.13 | Patlabor | in a rename scenario master -> 2.4.3 dev -> master, new branch from master to new dev |
| 05:58.16 | Patlabor | easy peasy |
| 05:58.29 | BulletCatcher | Saying you *want* to be done with 2.4.x doesn't mean we would actually be done with it. |
| 05:58.51 | Patlabor | allejo, if while developing 2.6 we need to make changes to 2.4.3 we make those changes in master |
| 06:00.40 | Patlabor | sure that's why you keep it, if you have to make changes, you branch from 2.4.3 to 2.4.3_maint |
| 06:00.40 | Patlabor | and fix from there |
| 06:00.42 | Patlabor | but that is a special case |
| 06:00.42 | Patlabor | something that should be rare |
| 06:02.02 | Patlabor | or heck, when master goes to 2.4.3, just call it 2.4.3_maint |
| 06:02.05 | Patlabor | it isn't a release bin so it doesn't matter |
| 06:02.26 | Patlabor | if you end up not going with a dev, you rename that to an archive branch and create your newedev fromw whatever source you want |
| 06:02.28 | Patlabor | it's all workable |
| 06:02.44 | Patlabor | so if we got deep in to 2.5.x and said "oops", we can archive of dev to 2_5_x_fail and make a new dev from master and try again |
| 06:02.48 | Patlabor | that should handle all the cases we have had, if rep renames are acceptable |
| 06:02.48 | Patlabor | if not then we need merges |
| 06:02.58 | Patlabor | if there is no techincal problem with repo renames I see no reason not to use them |
| 06:05.03 | allejo | how would _fail come about? wouldn't we just revert the changes instead? the history would remain |
| 06:05.07 | Patlabor | hitting history makes it harder to chery pick merges |
| 06:05.09 | Patlabor | see 2.99.x as an example :) |
| 06:05.18 | BulletCatcher | Successfully renaming branches requires all downstream repo copies to have the same name changes applied manually, but with the small size of our developer population I think that is doable. |
| 06:05.27 | Patlabor | we made a new dev branch off 2.2 to be released as 2.4, and pulled in only some changes from 2.99 |
| 06:05.56 | Patlabor | I just think it's easier to explain if we can tell people "master is compatable with the last release" |
| 06:06.02 | Patlabor | "Dev is for new stuff" |
| 06:08.23 | Patlabor | dev may or may not be compatible depending on what we are working on, but we can say that it's not ready for ANyone to use |
| 06:11.48 | Patlabor | or if we are working on compatable fixes maybe we won't have a dev at that time |
| 06:11.50 | Patlabor | depends how it goes |
| 06:12.25 | Patlabor | it shojld be flexabile enough to handle ether case that comes up |
| 06:12.25 | BulletCatcher | I think I can live with renaming v2_4_x to master and v2_6_x to dev. |
| 06:12.25 | BulletCatcher | When dev is released we would have to move the "master" name to it, but again I think the pain would be minimal. |
| 06:12.25 | Patlabor | then in november I can throw a unity project in there :) |
| 06:12.25 | allejo | there are far too many branches lol 2.99 net 2.99 shot 1.7 and 1.7 branch |
| 06:12.25 | Patlabor | yeah, I belive that is why BulletCatcher is sugesting we only bring over the 2 we need |
| 06:12.25 | Patlabor | leave the others on SF as an archive |
| 06:12.25 | Patlabor | or put them a seperate archive repo on github |
| 06:12.27 | Patlabor | we don't need them to be history linked |
| 06:12.27 | allejo | either would work |
| 06:12.27 | BulletCatcher | I haven't suggested that. The old branches would stay in the repo. |
| 06:13.39 | BulletCatcher | I'll try to put up a "release candidate" repo this weekend. |
| 06:16.51 | Patlabor | we have backups of it all so we can do that work at any time |
| 06:16.59 | Patlabor | cool |
| 06:17.16 | Patlabor | in Surround SCM I'd just do a rebase and be done |
| 06:17.22 | Patlabor | ahh ok |
| 06:17.29 | Patlabor | well where ever they are, it's fine |
| 06:17.30 | Patlabor | it dosn't affect the day to day |
| 06:17.31 | Patlabor | sorry month to month |
| 06:20.17 | Patlabor | bzflag_import_X |
| 06:20.17 | Patlabor | it'll be mysterious |
| 06:20.18 | allejo | bzflag_import_rc_1 :p |
| 06:20.20 | Patlabor | or just bzflag |
| 06:20.22 | allejo | please ^ |
| 06:20.23 | BulletCatcher | zuii: http://wiki.bzflag.org/Development_RoadMap is where we have written plans for future versions. No one has committed to actually doing anything described there. |
| 06:20.52 | zuii | yes, i read that |
| 06:27.28 | zuii | im going to make my repo just for play around |
| 06:28.43 | Patlabor | full server state is a very large project, I can not see it being done in a 2.6 timeframe |
| 06:28.44 | Patlabor | not unless there is a truely epic change in development practices |
| 06:28.55 | zuii | there are "little tasks" like "Case insensitive bans" at least it looks like |
| 06:28.55 | Patlabor | have fun with it :) |
| 06:28.55 | BulletCatcher | zuii: feel free to implement that and give us a pull request. |
| 06:28.56 | Patlabor | yeah there are a number of smaller things that can be done by individuals |
| 06:28.57 | zuii | what do you mean under "New Server List"? |
| 06:28.57 | zuii | whats new? |
| 06:28.57 | BulletCatcher | blast007 can answer that better than any of the rest of us. |
| 06:33.01 | Patlabor | there have been several proposals |
| 06:33.01 | Patlabor | a better way to display the data |
| 06:33.02 | Patlabor | groups, tabs, sorting by server or by map, etc.. |
| 06:33.03 | Patlabor | there should be some wiki articles with the writen up ideas |
| 06:33.04 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 06:33.33 | Patlabor | one of the SOC projects was about that, there should be documentation |
| 06:34.03 | Flash | Constitution: can't necessarily say there was a LOT of understanding in the changes to the project file. Most (all?) of that XCode did by itself. Finding access to where/how to change all those things is not at all straightforward. |
| 06:34.29 | Flash | I can agree with you about not modifying "upstream", but if that's really the case then maybe we shouldn't supply the source; rather just require people to have it installed? |
| 06:35.36 | Patlabor221 | I figured it was unintentional :) |
| 06:35.40 | Flash | as to the header guard, if you can find another instance of _PLUGIN_HTTP_H_, then you are a better searcher than I |
| 06:35.55 | Flash | yeah, git and I aren't quite friends yet |
| 06:36.09 | Flash | and XCode likes to help a bit more than I'd like |
| 06:41.02 | BulletCatcher | "git diff --cached" is the way to preview the changes that are going into the next commit. |
| 06:53.15 | BulletCatcher | Those of us still here got the short end of that netsplit. |
| 07:02.55 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 07:02.55 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 07:02.55 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 07:02.55 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 07:02.55 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 07:02.55 | *** join/#bzflag thrakt (cz3141@gateway/shell/devio.us/x-mbshhaoiagznoddu) |
| 07:02.55 | *** join/#bzflag meeba (~lamer@c-75-71-23-204.hsd1.co.comcast.net) |
| 07:02.55 | *** mode/#bzflag [+v DTRemenak] by asimov.freenode.net |
| 07:18.03 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 07:18.03 | *** join/#bzflag therealtbe (~AresHandl@pool-74-109-244-171.pitbpa.fios.verizon.net) |
| 07:18.03 | *** join/#bzflag nitroxis (~n@wtwrp.de) |
| 07:18.03 | *** join/#bzflag Notify (~notify@66-118-151-70.static.sagonet.net) |
| 07:18.03 | *** join/#bzflag brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 07:18.03 | *** join/#bzflag mahem1_ (~mahem1@216.249.42.52) |
| 07:18.03 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 07:18.03 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 07:18.03 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 07:18.03 | *** join/#bzflag Flash (~flash@bzflag/developer/Flash) |
| 07:18.03 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 07:18.03 | *** join/#bzflag delusional (~delusiona@pool-173-71-173-74.pitbpa.fios.verizon.net) |
| 07:18.03 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 07:18.03 | *** join/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-uvrxaqcvnjgileeu) |
| 07:18.03 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 07:18.03 | *** join/#bzflag Kaelten (Kaelten@WoWUIDev/WoWAce/WoWIFA/CurseStaff/kaelten) |
| 07:18.03 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 07:18.03 | *** join/#bzflag JPT (~jpt@jpt.lu) |
| 07:18.03 | *** join/#bzflag brad (~brad@unaffiliated/brad) |
| 07:18.04 | *** join/#bzflag MonsieurApple (~MonsieurA@unaffiliated/mrapple) |
| 07:18.04 | *** join/#bzflag McYukon (~McYukon@72.14.188.239) |
| 07:18.04 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 07:18.04 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 07:18.04 | *** join/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 07:18.04 | *** join/#bzflag Chestal (~thilo@vmax.unix-ag.uni-siegen.de) |
| 07:18.04 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 07:18.04 | *** mode/#bzflag [+vvov joevano L4m3r Chestal trepan] by asimov.freenode.net |
| 07:18.04 | *** join/#bzflag AAA_awright (~aaa@2607:5300:60:7d4::1) |
| 07:18.04 | *** join/#bzflag Plast (~plastix@unaffiliated/plast) |
| 07:18.04 | *** join/#bzflag TD-Linux (~Thomas@about/essy/indecisive/TD-Linux) |
| 07:18.04 | *** join/#bzflag tw1sted (~tw1sted@unaffiliated/tw1sted) |
| 07:18.04 | *** join/#bzflag mdskpr__ (~quassel@li59-174.members.linode.com) |
| 07:18.04 | *** join/#bzflag McSpider (~McSpider@72.14.188.239) |
| 07:18.04 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 07:18.04 | *** join/#bzflag bier (~bier@helixnetworks.de) |
| 07:18.04 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 07:18.04 | *** join/#bzflag rodgort (~rodgort@192.241.198.49) |
| 07:18.04 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
| 07:18.04 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 07:18.04 | *** mode/#bzflag [+o ChanServ] by asimov.freenode.net |
| 07:38.30 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 07:38.30 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
| 07:38.30 | *** join/#bzflag rodgort (~rodgort@192.241.198.49) |
| 07:38.30 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 07:38.30 | *** join/#bzflag bier (~bier@helixnetworks.de) |
| 07:38.30 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 07:38.30 | *** join/#bzflag McSpider (~McSpider@72.14.188.239) |
| 07:38.30 | *** join/#bzflag mdskpr__ (~quassel@li59-174.members.linode.com) |
| 07:38.30 | *** join/#bzflag tw1sted (~tw1sted@unaffiliated/tw1sted) |
| 07:38.30 | *** join/#bzflag TD-Linux (~Thomas@about/essy/indecisive/TD-Linux) |
| 07:38.30 | *** join/#bzflag Plast (~plastix@unaffiliated/plast) |
| 07:38.30 | *** join/#bzflag AAA_awright (~aaa@2607:5300:60:7d4::1) |
| 07:38.30 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 07:38.30 | *** join/#bzflag Chestal (~thilo@vmax.unix-ag.uni-siegen.de) |
| 07:38.30 | *** join/#bzflag alezakos (~kongr45gp@unaffiliated/alezakos) |
| 07:38.30 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 07:38.30 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 07:38.30 | *** join/#bzflag McYukon (~McYukon@72.14.188.239) |
| 07:38.30 | *** join/#bzflag MonsieurApple (~MonsieurA@unaffiliated/mrapple) |
| 07:38.30 | *** join/#bzflag brad (~brad@unaffiliated/brad) |
| 07:38.30 | *** join/#bzflag JPT (~jpt@jpt.lu) |
| 07:38.30 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 07:38.30 | *** mode/#bzflag [+ovov ChanServ trepan Chestal L4m3r] by asimov.freenode.net |
| 07:38.30 | *** join/#bzflag Kaelten (Kaelten@WoWUIDev/WoWAce/WoWIFA/CurseStaff/kaelten) |
| 07:38.30 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 07:38.30 | *** join/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-uvrxaqcvnjgileeu) |
| 07:38.30 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 07:38.31 | *** join/#bzflag delusional (~delusiona@pool-173-71-173-74.pitbpa.fios.verizon.net) |
| 07:38.31 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 07:38.31 | *** join/#bzflag Flash (~flash@bzflag/developer/Flash) |
| 07:38.31 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 07:38.31 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 07:38.31 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 07:38.31 | *** join/#bzflag mahem1_ (~mahem1@216.249.42.52) |
| 07:38.31 | *** join/#bzflag brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 07:38.31 | *** join/#bzflag Notify (~notify@66-118-151-70.static.sagonet.net) |
| 07:38.31 | *** join/#bzflag nitroxis (~n@wtwrp.de) |
| 07:38.31 | *** join/#bzflag therealtbe (~AresHandl@pool-74-109-244-171.pitbpa.fios.verizon.net) |
| 07:38.31 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 07:38.31 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 07:38.31 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 07:38.31 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 07:38.31 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 07:38.31 | *** join/#bzflag thrakt (cz3141@gateway/shell/devio.us/x-mbshhaoiagznoddu) |
| 07:38.31 | *** join/#bzflag meeba (~lamer@c-75-71-23-204.hsd1.co.comcast.net) |
| 07:38.31 | *** mode/#bzflag [+vv joevano DTRemenak] by asimov.freenode.net |
| 07:40.01 | *** join/#bzflag TheRedBaron (~ZeeBaronR@c-69-254-178-47.hsd1.fl.comcast.net) |
| 07:40.01 | *** join/#bzflag khazhyk_ (~khazhy@unaffiliated/khazhyk) |
| 07:40.01 | *** join/#bzflag kierra (~quassel@unaffiliated/kierra) |
| 07:40.01 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 07:40.01 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 09:50.40 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 09:52.19 | *** join/#bzflag death__ (~I_Died_On@2601:5:9880:327:f04a:dd7d:7f28:8adb) |
| 09:53.23 | Constitution | Flash: it's quite possible that Xcode threw a warning for the lack of that setting if you're using a later version than I was, so it could have been inserted automatically? regardless, it should be 10.7 if it is defined at all |
| 09:54.05 | Flash | actually, there's a warning about wanting me to sign my apps, but I at least knew enough to ignore that :) |
| 09:56.06 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 09:56.06 | *** join/#bzflag TheRedBaron (~ZeeBaronR@c-69-254-178-47.hsd1.fl.comcast.net) |
| 09:56.06 | *** join/#bzflag khazhyk_ (~khazhy@unaffiliated/khazhyk) |
| 09:56.06 | *** join/#bzflag kierra (~quassel@unaffiliated/kierra) |
| 09:56.07 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 09:56.07 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 09:59.01 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 09:59.01 | *** join/#bzflag Chestal (~thilo@vmax.unix-ag.uni-siegen.de) |
| 09:59.01 | *** mode/#bzflag [+vo L4m3r Chestal] by asimov.freenode.net |
| 10:11.26 | Constitution | yeeeaahhhh... |
| 10:15.18 | blast007 | if we were to make 2.4 be the stable version until the development version gets far enough along, that would make it difficult for server owners to track the current stable version... at some random point, their stable 2.4 would change to development 2.5 .... |
| 10:15.55 | blast007 | so I think that our stable releases should be in a branch so that when you pull changes, you're still getting the same compatible release |
| 10:16.24 | blast007 | master should be the bleeding edge dev version that is incompatible |
| 10:39.53 | blast007 | the "new server list" is the one that was created during GSoC for 2.99 |
| 10:44.04 | blast007 | let's take an example of a server owner running 2.4. With your proposed plan, master would be 2.4, and 2.5 would be in a dev branch. Let's assume the server owner has some local change to his server files. Then we release 2.6 and suddenly master pulls in hundreds or thousands of new commits, including cases where files are removed, or where major chunks of code are removed, refactored, or moved. Server owner does their usual update, and now t |
| 10:44.27 | blast007 | I think updating to the next major version should be a planned choice, not a surprise. |
| 10:45.51 | blast007 | what you're suggesting is like using the 'stable' keyword in your Debian sources.list and suddenly having your debian system start pulling packages from the new major stable version they pushed out - something that could break your system because there are specific upgrade steps you need to take |
| 10:46.25 | blast007 | (and Debian recommends not doing that for that exact reason and instead using the release codenames like 'wheezy' and 'jessie', not the generic names like 'stable' and 'testing') |
| 10:48.31 | blast007 | plus there is still going to be source .tar.gz files released, so the users you think aren't smart enough to figure out how to pull a specific git branch can just get those... the rest of us can pull the specific branch we want and update those as changes come and keep our sanity about which version we'll be getting on any given day |
| 11:38.23 | *** join/#bzflag Gnurdux (~Michael@c-24-128-51-69.hsd1.ma.comcast.net) |
| 12:15.26 | *** join/#bzflag I_Died_Once (~I_Died_On@2601:5:9880:327:f04a:dd7d:7f28:8adb) |
| 12:15.26 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:22.23 | Patlabor221 | blast007, no master would only change when we released 2.6 |
| 14:22.52 | Patlabor221 | and yeah, we WANT them to update |
| 14:24.15 | Patlabor221 | but another option is to have current code in a branch and then users that want that have to hunt for it |
| 14:28.06 | blast007 | sure, we want them to update, but we DON'T want it to be a surprise that hoses their local repo |
| 14:28.33 | blast007 | git can run into conflict situations just like any other VCS |
| 14:29.48 | blast007 | our users have been able to figure out that SVN trunk isn't compatible with the normal release even if they had to ask the first time |
| 14:29.53 | blast007 | why should Git be that much harder? |
| 14:30.35 | blast007 | not everything needs a technical fix... |
| 14:32.20 | blast007 | some of the things we could be doing for 2.6 could include writing some good end user documentation and throwing that on the main site instead of buried in random places on a wiki |
| 15:43.21 | *** join/#bzflag infobot (ibot@rikers.org) |
| 15:43.21 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/PI9KFD |
| 15:43.21 | *** mode/#bzflag [+o infobot] by ChanServ |
| 15:57.14 | *** join/#bzflag infobot (ibot@rikers.org) |
| 15:57.14 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/PI9KFD |
| 15:57.15 | *** mode/#bzflag [+o infobot] by ChanServ |
| 15:57.21 | *** join/#bzflag Flash (~flash@71.56.240.88) |
| 15:57.21 | *** join/#bzflag Flash (~flash@bzflag/developer/Flash) |
| 15:59.14 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 16:00.16 | *** join/#bzflag death__ (~I_Died_On@69.136.32.149) |
| 16:03.01 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 17:19.55 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 17:19.55 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 17:21.43 | Constitution | blast007: I don't disagree with you, but technically server owners who are building code from the git repo are already running unstable code |
| 17:22.58 | Constitution | running "git pull" isn't a conventional way of obtaining maintenance updates |
| 17:33.02 | BulletCatcher | Some commits to the 2.4 code are developmental (not well tested, and not necessarily suitable for use on public servers). |
| 17:33.05 | BulletCatcher | Others are recommended for general use. |
| 17:33.06 | BulletCatcher | Two branches of the 2.4 code would help distinguish between those. |
| 17:47.09 | Constitution | or we could push out releases faster, and encourage server owners to use actual stable code |
| 17:47.46 | Constitution | although our DR friend has been quite adept lately at finding "critical" issues that need to be patched |
| 17:49.34 | *** join/#bzflag swigg (~Paul@97-82-254-35.dhcp.hckr.nc.charter.com) |
| 17:49.34 | *** join/#bzflag swigg (~Paul@bzflag/player/Swigg) |
| 17:56.09 | Constitution | imho we are overdue for a 2.4 release? look at the changelog |
| 17:57.17 | BulletCatcher | The ChangeLog file isn't even up to date. :-p |
| 17:57.49 | BulletCatcher | But I agree that we have enough changes to justify releasing 2.4.4. |
| 17:58.48 | swigg | Glad you guys are still develloping. Bless you all! |
| 18:02.08 | Constitution | that is a somewhat dubious allegation ;) |
| 18:02.57 | BulletCatcher | Several commits were made in the last week. That counts. |
| 18:03.31 | *** join/#bzflag JPT (~jpt@mail.jpt.lu) |
| 18:05.36 | Constitution | although I suppose we should sort out the OS X 10.9/10.10 issues before proposing a release |
| 18:06.25 | Constitution | delusional, you said all the builds you tried crashed at launch on yosemite, right? |
| 18:06.38 | BulletCatcher | There are a couple of other issues I would like to see resolved before releasing 2.4.4, too. |
| 18:07.32 | BulletCatcher | The release process documented in the DEVINFO file takes 1-2 hours to follow, so we don't want to do that very often. |
| 18:07.33 | BulletCatcher | A release process that ends with a new Git tag or branch would be more appropriate for a faster cycle. |
| 18:08.48 | Constitution | maybe finalizing the repo structure would be one of those prerequisites to a release |
| 18:11.46 | Constitution | I will be setting up an yosemite install in the next week or two, at which point I will have a better idea where we stand on the mac platform |
| 18:12.34 | Constitution | the work I put in to try to make it work on mavericks did not leave me too hopeful |
| 18:13.45 | Constitution | meaning we may be looking at a SDL 2 upgrade, or an homemade mac platform implementation, either of which would be significant projects |
| 18:26.13 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 19:04.53 | swigg | zuii? Chirp-chirp? |
| 20:01.54 | *** join/#bzflag Patlabor (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 20:02.04 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 20:20.42 | allejo | what about a master branch containing latest code and a "2.4-release" branch which has latest stable code. and always pull from the release branch? |
| 20:21.03 | Patlabor | releases have specific numbers |
| 20:21.17 | Patlabor | if you want the maintenance for a releaed branch that'd be 2.4.Maint |
| 20:21.20 | Patlabor | or something |
| 20:21.27 | Patlabor | then you know it's not released yet |
| 20:21.32 | Patlabor | but that is a way to do it |
| 20:21.38 | Patlabor | master is unstable |
| 20:21.48 | Patlabor | and we have branches for the various states of stable |
| 20:23.46 | allejo | would seem fair |
| 20:24.51 | Patlabor | yeah it's reasonable |
| 20:25.11 | Patlabor | we'd just have to understand that people who want updated, release compatable code would have to be directed to a branch |
| 20:25.15 | Patlabor | and that's the same problem we have now |
| 20:25.29 | Patlabor | what it solves is developers not having to go to a branch |
| 20:25.58 | Patlabor | personaly I know we have more users then developers so that's why I put the code that users want in the master, rather then dev code in master, but ether system works |
| 20:40.34 | Patlabor | it's kinda bikeshed, one of the 2 groups has to be told to go somewhere else :) |
| 20:40.46 | Patlabor | I was prefering the dev group to be told that, they are more techincal |
| 20:44.36 | *** join/#bzflag Snake12534 (uid45641@gateway/web/irccloud.com/x-rvunxixryuqauxms) |
| 20:59.03 | blast007 | BulletCatcher: we're also not running life supports systems for a hospital, so is it really that bad if a server owner updates and encounters a bug? just means we can fix it faster if they let us know. |
| 21:00.33 | blast007 | I just think we're trying to make it more complicated than necessary... if we're worried about pushing an experimental change to a stable branch, then maybe just release it as a patch or as an altered source tar/zip and get people to test it and report if it's good/bad/ugly |
| 21:01.05 | blast007 | I think there's already several people (myself included) willing to test experimental patches |
| 21:01.10 | Patlabor | yeah |
| 21:01.15 | Patlabor | we just need to pick a place :) |
| 21:01.25 | Patlabor | having a maint branch is fine |
| 21:01.32 | Patlabor | it's what we have done in the past |
| 21:01.40 | Patlabor | master as dev is what we did in SVN |
| 21:02.31 | blast007 | so are you thinking something like what our git repo has right now, keeping 2.4.x in the v2_4_x branch but swapping v2_6_x to master? |
| 21:02.44 | Patlabor | yeah |
| 21:03.09 | Snake12534 | blast007: have you heard of stencyl? |
| 21:03.23 | blast007 | I think it's the most straight forward for people familiar with our old structure and it's similar to what other projects do (having bleeding edge code in master) |
| 21:03.34 | Patlabor | yeah it'll work prefectly fine |
| 21:04.20 | blast007 | Snake12534: I don't make games, but I did stay at a Holiday Inn Express last night. |
| 21:04.32 | Snake12534 | nice |
| 21:04.39 | blast007 | but not really |
| 21:05.02 | Snake12534 | ah |
| 21:05.06 | Patlabor | I just think it's silly we are still on "import 3" |
| 21:29.53 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 21:46.40 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 22:19.52 | BulletCatcher | Different people have different pre-conceived ideas of the purpose of the "master" branch. |
| 22:19.54 | BulletCatcher | The only way I see to please everyone is to please no one, and just have a README file on the master branch that directs people to the appropriate branch for their needs. |
| 22:21.51 | Patlabor | who said we have to pelase everyone? |
| 22:22.02 | Patlabor | what is the code repo for, mainly, users or developers? |
| 22:29.21 | BulletCatcher | If we make the 2.5 branch master, then non-developers will forever be asking us which branch to use (often after trying unsuccessfully to run whatever is on the master branch). |
| 22:29.24 | BulletCatcher | If we make the 2.4 branch master then inattentive developers will commit to the wrong branch, but I suppose that inattentive developers will do that no matter what we do. |
| 22:29.27 | BulletCatcher | If we put a "which branch should I use" FAQ (and only that) on the master branch then at least some people will read it and arrive at the correct result on their own. |
| 22:29.48 | Patlabor | we have that now, it confuses everyone |
| 22:30.03 | Patlabor | I agree with your developer statement |
| 22:30.53 | BulletCatcher | Perhaps the README file currently on the master branch just needs to be better written. |
| 22:30.54 | BulletCatcher | Patches welcome. |
| 22:36.23 | Patlabor | I do not think that is the problem |
| 22:41.34 | delusional | Constitution: My problem was related to a local user account password problem i was having. Trying to limit my exposure to the cloud i had also locked myself out of some system files. BZFlag could not read or write to config.cfg... Once i cleared that up, all was good. |
| 22:42.25 | delusional | Should also note that i had been using the yosemite beta release, which called for your nogamma2 build |
| 22:44.31 | delusional | ... so my crash bug was not BZ's fault |
| 22:45.23 | BulletCatcher | Okay, then the repo I post tomorrow will have the 2.4 branch be master. |
| 22:45.29 | Patlabor | cool |
| 22:52.49 | alezakos | if you want more semantic branch names, note that the default branch doesn't have to be called master (a repo can actually have no "master" branch) |
| 23:07.41 | Patlabor | super_cool_branch |
| 23:11.27 | gnu-sense | lord_branch and serf_branch |
| 23:11.53 | gnu-sense | or general and pfc |
| 23:12.07 | Patlabor | I am partial to "mainline" as opposed to "master" |
| 23:12.12 | Patlabor | but ether work for me |
| 23:12.26 | Patlabor | it's "the version you should use unless you know better" |