| 00:25.08 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 01:29.39 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 02:45.40 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
| 02:46.34 | macsforme | I have an alternative idea for how to lay out our branches for development in git |
| 02:51.09 | macsforme | what we have now is 2.4, which is stable and should remain so in case we need to push out minor fix releases, and master, which has a new protocol and where all new major development is supposed to go |
| 02:53.56 | macsforme | several more complex projects have been turned down for 2.4 due to stability concerns, and when you do projects in master you are kind of on your own in the dark, since you cannot easily test stuff with few servers and no players using that protocol |
| 02:59.12 | macsforme | my personal interpretation of the 2.99 failure is that it was difficult and unrewarding to develop/profile/test in a codebase with no users |
| 03:00.50 | macsforme | so, to facilitate some of the bigger refactoring and improvements that some of us want to do, I propose that we do this: |
| 03:03.31 | macsforme | make 2.4 our super-stable maintenance branch, where only small fixes or improvements will go, and we can push new releases out quickly if we need to (like the last few that we have done) |
| 03:08.11 | macsforme | make a new "master" branch from the current head of 2.4; this branch will maintain protocol compatibility, but complex refactoring and internal improvements are free to take place here... so this will be a less stable branch, but still protocol compatible so improvements and new features can be readily tested on 2.4 servers |
| 03:12.00 | macsforme | then either a) create a new branch, called "breaking" or something similar, where protocol-breaking or gameplay-altering features will be staged, or b) create individual pull requests for such features to go into master, but leave them staged there for now |
| 03:16.24 | macsforme | then, prior to the next major release, we can merge "breaking" into "master" (or merge in all the breaking pull requests), bump protocol, and we will only have to test the effects of the "breaking" features prior to setting up the next major release |
| 03:18.40 | macsforme | I think doing a "breaking" branch is preferable to individual pull requests, but I think either way is feasible |
| 03:20.34 | macsforme | thoughts? |
| 03:24.43 | macsforme | allejo, I know you have a few complex projects that could be done in a protocol-compatible branch, like the group permissions overhaul, bz_eGetWorldEvent, the new configuration file format, etc.... what do you think? |
| 03:28.25 | macsforme | and I hope BulletCatcher can weigh in since the initial git import was kind of his baby |
| 04:13.11 | BulletCatcher | The baby is grown up and long gone from the nest, but I do have some insights. |
| 04:13.18 | BulletCatcher | Git makes it as easy as possible to develop complex changes (new features, refactoring, etc.) on their own branches before merging onto a release branch. |
| 04:13.21 | BulletCatcher | I don't really care whether that is done in a simple Git branch or in a pull request (which is a just a branch, but with special management by GitHub). |
| 04:13.26 | BulletCatcher | Obviously, people without direct write access to our GitHub repo would only be able to do pull requests. |
| 04:13.30 | BulletCatcher | I like the idea of having more meaningful branch names (e.g., "breaking", although even that requires unsupplied context), which means that "master" would have to go. |
| 04:13.33 | BulletCatcher | We do need to have the discipline to merge sufficiently completed changes onto the main development branch(es) to ensure they get adequate testing. |
| 04:13.37 | BulletCatcher | Otherwise, we'll decide to do a release, merge a bunch of outstanding changes, and not know whether they work together. |
| 04:13.39 | BulletCatcher | Lastly, at least once I'd like to try a rebase in the public repo to make the branches less messy and to see whether we have a real problem with developers inadvertently pushing back the old commits. |
| 05:38.30 | JeffM | Damn, I accidentally made water level look bitchen https://usercontent.irccloud-cdn.com/file/Fgv406Fp/frame_0030.png |
| 05:40.53 | JeffM | https://www.hyperdrive.tech/BZU/previews/hix_water.gif |
| 06:30.08 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 06:38.34 | allejo | macsforme, I would love to make use of a setup like that. like BC said, these would be "feature branches" so it's still following git practices/conventions |
| 06:39.25 | allejo | if we're gonna start with large changes in separate branches, i'd want to revisit unit tests again so we can have some indicator if something breaks in an obvious manner |
| 06:40.47 | allejo | there's a convention I've seen in a few repos where branch names have a "/" and some git guis organize those branches into respective "folders" |
| 06:41.21 | allejo | for example, "wip/bz_eGetWorldEvent" could be a branch |
| 06:41.55 | allejo | I know SourceTree and GitKraken can display these branches into a virtual folder |
| 07:30.21 | allejo | on an unrelated note, for the Xcode project, is there a reason why the plugin schemas aren't set to execute with bzfs loading the plugin by default? this probably just opinion |
| 07:30.37 | allejo | scheme* |
| 07:31.09 | allejo | i.e. when you run a scheme for a plugin from Xcode, it'd run with the bzfs target and using -loadplugin as an option |
| 09:31.05 | *** join/#bzflag cods (~fred@rsbac/developer/cods) |
| 09:31.05 | *** mode/#bzflag [+v cods] by weber.freenode.net |
| 09:31.05 | *** mode/#bzflag [-v cods] by ChanServ |
| 10:39.39 | blast007 | Unit tests seem to work better for libraries. I'm not sure how to make them work for things that build an executable file. |
| 10:46.59 | *** join/#bzflag jcp__ (sid143528@gateway/web/irccloud.com/x-nsednmrvfkoyxfhf) |
| 12:33.20 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 12:33.20 | *** mode/#bzflag [+v joevano] by ChanServ |
| 13:52.57 | macsforme | allejo: I'm not opposed to that, I just don't know offhand how to configure it |
| 13:54.22 | blast007 | with courage |
| 13:54.41 | macsforme | feel free to try it |
| 13:54.54 | blast007 | I don't have that much courage |
| 13:55.03 | macsforme | not you :P |
| 13:55.10 | blast007 | ;) |
| 13:56.53 | macsforme | ultimately I want to move toward a single build configuration that automatically creates project files for us, and I don't know how much we will have access to such complex features of Xcode |
| 13:57.38 | blast007 | https://xkcd.com/927/ |
| 13:58.00 | blast007 | I'd rather keep platform specific build configurations where it makes sense |
| 14:02.54 | macsforme | no doubt there would have to at least be some platform-specific configurations within that system... I guess we will see when we actually try it out |
| 14:14.17 | macsforme | BulletCatcher and allejo, feature branches are great, and we should use them, but then the issue is where they would get merged in |
| 14:15.01 | macsforme | we want to keep 2.4 stable in case we need to push out another release, and 2.5 is difficult (impossible for some things) to test |
| 14:16.00 | macsforme | I would personally like a branch that remains protocol compatible so you can see what you're doing, but is open for major refactoring and improvements |
| 14:17.20 | macsforme | if we did feature branches and pull requests only, I am afraid pull requests would sit there for months like they have done, and pull requests would start to depend on other pull requests and it might become more difficult to navigate them |
| 15:48.13 | blast007 | #MakeBZFlagGreatAgain |
| 15:54.57 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 15:56.51 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-msukbpigoehyhtoc) |
| 16:08.14 | JeffM | techincaly I am building walls right now |
| 16:08.22 | blast007 | :) |
| 16:08.31 | blast007 | but why is gonna pay for it? |
| 16:08.34 | blast007 | who* |
| 16:08.43 | JeffM | "them" |
| 16:09.28 | JeffM | I'm more pleased with the water tho |
| 16:31.19 | JeffM | my only sugestions for macsforme 's ideas is 1) make sure it's clear what place new devs use to get up to speed, and 2) don't spread yourself too thin between compatible and breaking stuff. |
| 17:01.57 | *** join/#bzflag ZLSA (uid97184@gateway/web/irccloud.com/x-dlfssthyzmrtnyuc) |
| 17:43.14 | blast007 | isn't #2 already a problem? |
| 18:12.26 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 18:15.10 | allejo | I don't think we really have the resources/motivation to fully work on a proto breaking branch. if we did, there'd be more done with 2.5 |
| 18:17.56 | *** join/#bzflag blast007_ (~blast007@bzflag/developer/Blast) |
| 19:00.49 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-rcaqqgvkjzhyifid) |
| 20:27.26 | JeffM | yeah |
| 20:27.33 | JeffM | so why even bother having one? |
| 20:28.01 | JeffM | make people do breaking things in forks then pull request them into your mainline when you decide to break |
| 20:34.02 | blast007 | how is that different than just putting the changes into master? |
| 20:35.11 | blast007 | changing our branches around isn't going to make people suddely want to contribute code |
| 20:35.43 | JeffM | <PROTECTED> |
| 20:36.03 | JeffM | I'm saying why even have a branch at all that isn't compatible |
| 20:36.44 | JeffM | you have your 2.4.x maint branch (his super stable), and your 2.4.dev branch that has stuff that is compatible but not "stable" |
| 20:36.53 | JeffM | so still useable on servers for testing |
| 20:37.31 | JeffM | then when someone wants to make your master (2.4.dev) branch incompatabile, you have them do it in a fork, test that fork, and when it's ready you merge into master and that's your new incompatible release |
| 20:37.57 | JeffM | I dunno, I just see that if nobody commits to a "breaking" branch, why even have one? |
| 20:40.09 | blast007 | 2.5 is different than 2.99 |
| 20:40.21 | JeffM | k |
| 20:40.22 | blast007 | 2.99 had *too much* work done on it |
| 20:40.30 | blast007 | 2.5 has barely been touched |
| 20:40.43 | blast007 | most of what's in there is my bad attempt at a dialog system |
| 22:57.34 | allejo | "WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h." |
| 22:58.13 | allejo | fwiw macsforme, that's the message I get when I launch from the command line |
| 22:59.04 | blast007 | does that mean that SDL2 is the problem there? |
| 23:03.24 | allejo | actually, let me test a more recent client |
| 23:05.18 | allejo | yeup, still there in 2.4.8 and and been there since at least 2.4.3 which is what I was running |
| 23:13.05 | allejo | running on 10.11 also |
