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

Closed
wolfgar opened this Issue Feb 21, 2014 · 11 comments

Comments

Projects
None yet
4 participants
@wolfgar
Member

wolfgar commented Feb 21, 2014

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

@wolfgar wolfgar added the question label Feb 21, 2014

@smallint

This comment has been minimized.

Show comment
Hide comment
@smallint

smallint Feb 21, 2014

Member

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?

Member

smallint commented Feb 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@koying

koying Feb 21, 2014

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 commented Feb 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@smallint

smallint Feb 21, 2014

Member

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
Member

smallint commented Feb 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@koying

koying Feb 21, 2014

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

koying commented Feb 21, 2014

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

@wolfgar

This comment has been minimized.

Show comment
Hide comment
@wolfgar

wolfgar Feb 22, 2014

Member

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

Member

wolfgar commented Feb 22, 2014

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

@wolfgar

This comment has been minimized.

Show comment
Hide comment
@wolfgar

wolfgar Feb 23, 2014

Member

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

Member

wolfgar commented Feb 23, 2014

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

@koying

This comment has been minimized.

Show comment
Hide comment
@koying

koying commented Feb 23, 2014

Great.

@koying

This comment has been minimized.

Show comment
Hide comment
@koying

koying Feb 23, 2014

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

koying commented Feb 23, 2014

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

@TheCoolDude

This comment has been minimized.

Show comment
Hide comment
@TheCoolDude

TheCoolDude Feb 23, 2014

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 commented Feb 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@wolfgar

wolfgar Feb 24, 2014

Member

@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...

Member

wolfgar commented Feb 24, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@wolfgar

wolfgar Feb 25, 2014

Member

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

Member

wolfgar commented Feb 25, 2014

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

@wolfgar wolfgar closed this Feb 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment