Pages: « 1 2 3 »
  Print  
Author Topic: Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev  (Read 6985 times)
Offline (Unknown gender) forthevin
Reply #15 Posted on: June 05, 2013, 05:43:37 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
Gahhhh. Thinks are getting too heated over mouse_x/mouse_y. polygone, it would be nice if you are a little bit more careful with your commits in the future. Others, mouse_x/mouse_y was likely a mistake from polygone's side, but hardly the end of the world.

I would also appreciate any comments on the guidelines I proposed.

polygone: I am currently looking into set_synchronization, and noticed that it had been commented out earlier in the Windows platform system. Do you remember why we did that? The code looks like it could work, though I haven't tried it out yet. I also wonder if it is related to dependencies, including glew, which may have been solved by the new bridges that have been made.

Robert: I think unit testing would be a very nice thing to have. I have thought about it myself, and I think it would also be nice to have different groups of tests so to say, such that if you made changes to graphics, you can run just tests related to graphics without running tests related to other stuff like sound. That said, I haven't looked much into it yet. I also think it would be very nice if the tests we make at some point can be easily be integrated into the automated regression testing on the site that I and Josh briefly talked about in the thread about the site.
Logged
Offline (Male) polygone
Reply #16 Posted on: June 05, 2013, 05:46:21 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Of course polygonz, you are rigth all of our bugs are fixed STRAIGHT AWAY amirite?
I wasn't referring to all the bugs, I was referring to this regression which the cause was perfectly known already.

polygone: I am currently looking into set_synchronization, and noticed that it had been commented out earlier in the Windows platform system. Do you remember why we did that? The code looks like it could work, though I haven't tried it out yet. I also wonder if it is related to dependencies, including glew, which may have been solved by the new bridges that have been made.
Yes, it was because of the dependencies.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Goombert
Reply #17 Posted on: June 05, 2013, 06:01:17 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Ya polygonz and we got enough bugs already without you implementing ones for the fuck of it.


@forthevin, no I was not aware I must not have payed attention to the website post, didnt really interest I am fine with the site except these forum bugs like the PM stuff.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) polygone
Reply #18 Posted on: June 05, 2013, 06:05:23 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Ya polygonz and we got enough bugs already without you implementing ones for the fuck of it.
It's not there any more.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Josh @ Dreamland
Reply #19 Posted on: June 05, 2013, 06:06:06 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2960

View Profile Email
polyfuck: How important a particular feature is does not pertain to the issue at hand. The issue is that the tracker is overflowing with little shit, the IRC is full of people who can't get the installer working, and amid all of that chaos, someone mentions, "Oh hey, mouse_x and _y aren't working."

Anyway, thanks much for the post, forthevin.
What I'm personally thinking is that we should do what we did on the SVN, only a little cleaner. I propose that everything in master be deemed "stable"; that is, no changes are made to it which have not been tested. Changes for testing are merged into the "testing" branch, from the "development" branch, when it's deemed that it might be a good time to push to stable.

Bug reports should be fixed in the most stable branch exhibiting the bug. That is, a bug should be fixed in master if it exists in master, otherwise it should be fixed in testing, or otherwise in development. If a bug is fixed in master, the fix is then merged into testing and development. If a bug is fixed in testing, it is merged into development. Bugs fixed in development, as stated, should have only been fixed there because they are absent from master and testing.

What I've just described is so simple, it's probably standard. The only reason we *aren't* doing that is because we failed miserably at it with the SVN, because no one ever remembered, "Hey, this would be a good revision to mark for (testing|stable)!"

If I thought we were responsible enough not to have a three-month-dead master branch on that system, I'd be interested in pursuing it.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) polygone
Reply #20 Posted on: June 05, 2013, 06:08:28 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
polyfuck: How important a particular feature is does not pertain to the issue at hand. The issue is that the tracker is overflowing with little shit, the IRC is full of people who can't get the installer working, and amid all of that chaos, someone mentions, "Oh hey, mouse_x and _y aren't working."
Then they got it fixed two seconds later. I'm sure their day was ruined by it.

« Last Edit: June 05, 2013, 06:13:33 PM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Josh @ Dreamland
Reply #21 Posted on: June 05, 2013, 08:21:27 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2960

View Profile Email
I didn't say that the issue ruined anyone's day (Even though I strongly implied it ruined mine). I said it was an issue. An issue that could have been easily avoided by using a branch. Four steps here:
  • Create a branch. git checkout -b ima_break_some_shit_to_move_mouse_x_and_y
  • Implement fix. This is the hard part, that you were going to do anyway.
  • Commit and push your fix. git commit -m "i fixd the shit on winblowx and brok it on evry1 els" git push origin ima_break_some_shit_to_move_mouse_x_and_y
  • Tell people on Linux and Mac to check out your branch and fix the shit on Linux and Mac, respectively.

From there, all anyone has to do is check out your branch, implement a fix, and merge the branch back into master. Now no one ever has to incur a problem.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #22 Posted on: June 05, 2013, 10:31:44 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
Also, if you've already made some code, but haven't committed it yet, but are ready to, you can still checkout the branch. So the first two steps can be done out of order.
So for example, I'm going to start moving mouse_x and mouse_y. I'm not sure how much work is involved, but it seems fairly simple. So I'm on master, I start work, and then the end of the day rolls around and I realize that I'm going to have to commit broken code. That's ok, just
Code: [Select]
git checkout -b moving_mouse and then
Code: [Select]
git commit -m "moving mouse. Shit done broke."
If, however, you already committed to master (but haven't pushed hopefully), not a big deal, just a couple more steps. Create your branch. At this point, both master and the branch will have the commit. We don't want master to have the commit yet, so we're going to roll him back. If you have any uncommitted changes, please make sure to commit or shelve them first, as they will be lost.
Code: [Select]
git checkout master
git reset --hard HEAD^
git checkout moving_mouse
Add more carets after HEAD according to how many commits you made (e.g. 2 commits = HEAD^^). Alternatively, you can just name the commit before yours in place of HEAD^.
« Last Edit: June 06, 2013, 09:39:55 AM by IsmAvatar » Logged
Offline (Male) Goombert
Reply #23 Posted on: June 06, 2013, 01:07:48 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Ha Ism, try [ ] not <>
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) polygone
Reply #24 Posted on: June 06, 2013, 06:23:07 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
I didn't say that the issue ruined anyone's day (Even though I strongly implied it ruined mine).
Yes it seems to only be you and Robert that it affected, even though neither of you were actually needing it to develop anything. It seems to me that's your own fault for having a bad perspective and not knowing what's going on correctly with ENIGMA.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) TheExDeus
Reply #25 Posted on: June 06, 2013, 07:57:12 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
I am pretty sure this is all blown out of proportion and I would personally not care about any of this. I don't think anything has to change because of this. I am just happy that there is actually progress that involves more than one person. In the past several years there were brief times of progress that was a doing of one person (like when I came and did drawing functions and path functions while no one else committed anything for 6 months). So this is a good change indeed. And it did work on Windows, which I care about. Josh didn't care for windows for years, so I won't care for linux either. So poly, break it.
Logged
Offline (Female) IsmAvatar
Reply #26 Posted on: June 06, 2013, 10:13:12 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
Can we try to keep this on topic? If you want to discuss aa smoothing, do so in another topic.

JOSH-EDIT: Split the topic. Posts about AA are now in THIS topic.
« Last Edit: June 07, 2013, 11:05:16 AM by Josh @ Dreamland » Logged
Offline (Unknown gender) forthevin
Reply #27 Posted on: June 06, 2013, 12:31:58 PM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
polygone: Thanks for the info, that is very useful.

Josh: So basically, bug fixes flow from the branch master to testing to development, while new features and additions flow the other way. That should make things more stable and let us spend less time on regressions, but it would also make development and addition of new features slower more cumbersome. I still think it is too early to adopt such a system, though I agree that adopting a process that increases stability is a good idea at this point in time.
Also, I added a link to your post regarding using git in the guidelines.

IsmAvatar: I added a link to your post regarding using git as well.

After giving it some thought, I think it may make sense to make a simple to follow and understand policy regarding committing to the master branch, and then referring to these guidelines as to the overall thoughts and purpose behind it, as well as for recommended ways to follow the policy. I think the policy would go something like:

  • Commits to the master branch should strive towards not breaking already working parts.
  • Changes that are known to break working parts should not be committed to the master branch, unless the breaking are known and accepted by the other developers and contributors.
  • Use forks or branches and inform others of the issues if you cannot fix or test the issues themselves, such that others can look at, test or fix them, before merging them into the master branch.

By having a policy we can avoid discussing a specific action and instead just refer to the policy, and then discuss the policy separately if there is disagreement about it. The policy doesn't cover everything, but it does cover the minimum, and I think that allows a fair amount of flexibility while still being somewhat effective. What do you think?
Logged
Offline (Female) IsmAvatar
Reply #28 Posted on: June 06, 2013, 03:28:01 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
Looks good. This information should go on the wiki, under something like ENIGMA:Developing
Logged
Offline (Unknown gender) forthevin
Reply #29 Posted on: June 08, 2013, 08:34:22 AM

Contributor
Joined: Jun 2012
Posts: 171

View Profile
I have written the guidelines and the policy into the wiki under the page IsmAvatar linked.
Logged
Pages: « 1 2 3 »
  Print