Proposal for guidelines on changes to the master branch of enigma-dev/enigma-dev

[forthevin]

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.

[polygone]

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.

[Goombert]

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.

[polygone]

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

It's not there any more.

[Josh @ Dreamland]

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.

[polygone]

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.

[Josh @ Dreamland]

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. [snip]git checkout -b ima_break_some_shit_to_move_mouse_x_and_y[/snip]
• Implement fix. This is the hard part, that you were going to do anyway.
• Commit and push your fix. [snip]git commit -m "i fixd the shit on winblowx and brok it on evry1 els"[/snip] [snip]git push origin ima_break_some_shit_to_move_mouse_x_and_y[/snip]
• 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.

[IsmAvatar]

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_mouseAdd 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^.

[Goombert]

Ha Ism, try [ ] not <>

[polygone]

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.

[TheExDeus]

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.

[IsmAvatar]

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.

[forthevin]

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?

[IsmAvatar]

Looks good. This information should go on the wiki, under something like ENIGMA:Developing

[forthevin]

I have written the guidelines and the policy into the wiki under the page IsmAvatar linked.