Skip to content
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
Closed

xbmc-imx6 workflow #6

wolfgar opened this issue Feb 21, 2014 · 11 comments
Labels

Comments

@wolfgar
Copy link
Member

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

@smallint
Copy link
Member

@smallint 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
Copy link

@koying 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
Copy link
Member

@smallint 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
Copy link

@koying koying commented Feb 21, 2014

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

@wolfgar
Copy link
Member Author

@wolfgar wolfgar commented Feb 22, 2014

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

@wolfgar
Copy link
Member Author

@wolfgar wolfgar commented Feb 23, 2014

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

@koying
Copy link

@koying koying commented Feb 23, 2014

Great.

@koying
Copy link

@koying koying commented Feb 23, 2014

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

@TheCoolDude
Copy link

@TheCoolDude 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
Copy link
Member Author

@wolfgar 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
Copy link
Member Author

@wolfgar 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
Labels
Projects
None yet
Development

No branches or pull requests

4 participants