xbmc-imx6 workflow

[wolfgar]

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.

• This github organization is the place where imx6 development effort now takes place
• Following Chris advice, I have created it in order to ease developers collaboration and to prepare for a pull request on XBMC main repository to add official support for imx6.
• A branch has to be the one which is ready for this PR. This branch has to be always rebased vs xbmc master so that at the end the whole patch will apply on head.
  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
• In this imx6 repository developers can have their own branch. All contributions are subject to a PR before being merged in master.
  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...
• At last, in xbmc-imx6 the issues will be the favorite place
  • To discuss new feature to be implemented (and assign job to prevent work duplication)
  • To exchange on related topics
  • To report bugs (if any lol)

Apart from this, all contributions are very welcome and encouraged of course !
I am looking forward to your feedback...

[smallint]

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?

[smallint]

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?

[koying]

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.
So I propose that only he would have the "merge" power for everything other than obvious bugfix.
Also, to cope with TZ / availability, we should leave at least 24h for everyone to have a chance to review/comment

Those rules might be a bit burdensome, but they are key to quality and non-frustration, from experience.

[koying]

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.
So I propose that only he would have the "merge" power for everything other than obvious bugfix.
Also, to cope with TZ / availability, we should leave at least 24h for everyone to have a chance to review/comment

Those rules might be a bit burdensome, but they are key to quality and non-frustration, from experience.

[smallint]

Agreed ... that sounds like a plan. To summarize:

• At least 24h after the last comment before closing an issue or making decisions. If in doubt, Stephan has the last word on it
• All major (to be defined) PR into master need confirmation from Stephan
• Rebase master into master-pr once a week

[smallint]

Agreed ... that sounds like a plan. To summarize:

• At least 24h after the last comment before closing an issue or making decisions. If in doubt, Stephan has the last word on it
• All major (to be defined) PR into master need confirmation from Stephan
• Rebase master into master-pr once a week

[koying]

Yep. Re major definition, I'd say anything that changes the current logic + new functionalities.

[koying]

Yep. Re major definition, I'd say anything that changes the current logic + new functionalities.

[wolfgar]

Thanks to you for your feedback : Perfectly fine with your conclusions

[wolfgar]

Thanks to you for your feedback : Perfectly fine with your conclusions

[wolfgar]

I have just published a post to spread the word regarding this new organization...

[wolfgar]

I have just published a post to spread the word regarding this new organization...

[koying]

Great.

[koying]

Great.

[koying]

I have rebased vs. xbmc master and created the master-pr branch

[koying]

I have rebased vs. xbmc master and created the master-pr branch

[TheCoolDude]

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]

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.

[wolfgar]

@TheCoolDude you are very welcome
But please note that geexbox has not yet switched to this repo : I am confident it will happen very soon and you will be able to test and report xbmc issues here...

[wolfgar]

@TheCoolDude you are very welcome
But please note that geexbox has not yet switched to this repo : I am confident it will happen very soon and you will be able to test and report xbmc issues here...

[wolfgar]

I close this question as generic guidelines have been established...

[wolfgar]

I close this question as generic guidelines have been established...