Include my major changes to the releases doc.

[s0undt3ch]

No description provided.

[s0undt3ch]

@thatch45 feel free to remove anything that you think ain't that important.

[SEJeff]

Cheater! Merging your own commits. I just push straight for obvious stuff like this and then only open a pull request on something I want someone else to look at.

[thatch45]

@s0undt3ch pushing directly would be ok as well for obvious stuff, but I have no issue with accepting your own pull reqs, I do like to see the notification of the opened pull reqs

[s0undt3ch]

Busted! ;)

I'll explain why, I, until now, have merged some of my own pull requests.

• they're obvious
• they don't actually change anything that drastically
• does not introduce new stuff

Why don't I do this directly?

I find it a pain to keep 2 local repos of the same project, I have a single virtualenv for all developments unless there's a specific reason why it should be in another virtualenv.

Having 2 of them would probably mean 2 virtualenvs, if a fix was first made on my own repo, I'd have to transplant it to the other repo, etc, a waste of time.

So, unless this is not acceptable, I'd like to keep it like this, I'm fine with not merging my own changes though if that's also not acceptable.

If there's a clean way to have 2 repos under the same project directory that we can switch to like if it was a git checkout <branch>, I'd like to know, I love learning new stuff.

[s0undt3ch]

Hmm, when I want to merge salt repo changes into my own I do:

git pull upstream develop

Can I also do:

git push upstream develop

?

[thatch45]

Yes, you should be able to without issue

[s0undt3ch]

Ok, Thanks!

And @thatch45 the proper way? ie, the salt way should be? Either way?

[thatch45]

for trivial stuff you can go direct, for anything that should be reviewed or somewhat substantial another member of the team should accept the pull request

[s0undt3ch]

Will try not to forget. Thanks!

[SEJeff]

@thatch45 Concur