New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xbmc-imx6 workflow #6
Comments
Unfortunately my git experiences are not yet very mature. We just switched recently from subversion to git and I still need to learn a lot regarding best practices. A master-pr branch sounds good but committing into both does not. Can't someone just rebase from time to time master-pr which is also merged from master? Regarding merging into master I would say that we need at least four eyes: two of the developer who created the PR and two of a reviewer who accepts the PR. A PR should never be accepted by the creator unless there are good reasons to do so. No idea how to put "good reasons" into a guidline though. ;) How are other projects dealing with this? |
Agree with both ;-) Re master-pr, I suggest to rebase say once a week. We can then backport to master any rebase fixes that would be needed. Re PR reviews, imo wolfgar should have the final say to anything of importance. None of this would exist without his work, so I consider him the owner. Those rules might be a bit burdensome, but they are key to quality and non-frustration, from experience. |
Agreed ... that sounds like a plan. To summarize:
|
Yep. Re major definition, I'd say anything that changes the current logic + new functionalities. |
Thanks to you for your feedback : Perfectly fine with your conclusions |
I have just published a post to spread the word regarding this new organization... |
Great. |
I have rebased vs. xbmc master and created the master-pr branch |
Hello! Nice to see a place where you can find XBMC devel. I would like to volunteer 1 of my Cubox-I 4 Pro for testing releases. I have 1 running geexbox-devel-20140218-r16877 with some success but still buggy. Will try geexbox-devel-20140221-r40018d6.cuboxi later today. I hope I can be of help to get an optimized XBMC release. |
@TheCoolDude you are very welcome |
I close this question as generic guidelines have been established... |
Hi
Sorry to bring a little boring stuff here,
I would just like to clarify a few things regarding the way of working in this repo in order to be able to write a note which describes it.
Initially master branch was supposed to be this candidate.
I would like to keep a branch which is the most uptodate content without jeopardizing hashes that may be useful for build systems (as some people already who package our work.)
Maybe we could have master branch which is a merge branch and another branch (lets say master-pr) which holds basically the same content but which is constantly rebased ? If we adopt this way of working merges will have to be pushed both in master and master-pr of course.
I am not sure it is a good idea : I am only trying to find a way to address all needs and suggestions are very welcome
Should we define something regarding how decisions are taken regarding these PR (who decides ? after how much time ? mandatory review ? ) ? I am asking to be able to write guidelines but I do not wish to burden the whole process. Again I would like your feedback...
Apart from this, all contributions are very welcome and encouraged of course !
I am looking forward to your feedback...
The text was updated successfully, but these errors were encountered: