search

edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:
https://edison-fw.github.io/meta-intel-edison/
MIT License
60 stars 37 forks source link

Fix repo references after moving to edison-fw org #26

Closed alext-mkrs closed 6 years ago

alext-mkrs commented 6 years ago

I've not corrected all of the references in README.md on purpose - as those currently left are about meta-intel-iot-middleware layer, which we don't use any more anyway and it's just that the whole readme needs an overhaul. I'll send a PR proposal later.

Other than that there were just a few fixes. The build is still running for me, so @htot, please don't merge it just yet - for now please take a look and tell me if it looks ok for you. When my build is [successfully] done, I'll merge it.

htot commented 6 years ago

Looks fine too me

htot commented 6 years ago

So how would the process work now? Let's say I have a commit for meta-acpi (which I have), I need to clone edison-fw/meta-acpi to htot/meta-acpi and push it there, right? Because right now (without cloning) pushing to htot/meta-acpi would go directly to edison-fw/meta-acpi (I think).

alext-mkrs commented 6 years ago

So there are basically two options - you either clone the edison-fw/meta-acpi, make a "feature", temporary, branch and then send a pull request from that branch to master, or create a fork in htot/meta-acpi, create a branch and then send a pull request from that to edison-fw/meta-acpi:master.

The latter used to be the recommended GH flow. The difference is that you have a full total copy of the repo you can mess with, not influencing the main repo in any way.

Here's some description of the flow: https://help.github.com/articles/working-with-forks

Either way, I'd keep my previous proposal of having all changes through pull requests, so that everything is peer-reviewed, I've learned over time that even in the most simple-looking changes there are sometimes pitfalls one doesn't think of. And that helps keep everyone on the same page. They can be self-merged, but the review is IMHO quite important.

All right, my build test also went fine, so I'm merging this one - thanks for taking a look.

alext-mkrs commented 6 years ago

This whole chapter may also be handy actually: https://help.github.com/categories/collaborating-with-issues-and-pull-requests/