Graphyte: Code re-use with public factory repo |
||
Issue descriptionGraphyte framework re-uses some utility functions and device link layer from public factory repo. Currently we copy-and-paste these source code, because we had modified some code when porting. Now it becomes hard to maintain when we update the code. Need a better way instead of copy-and-paste source code. Now Graphyte framework uses these modules: - cros.factory.utils.* - cros.factory.device.links.* There are some solutions for this issue: 1. Move the whole Graphyte framework back to factory repo. Should be the easiest one. Add a new item in Makefile, then we can use "make graphyte" to generate python package. 2. Create a new ebuild for "factory utils", then let Graphyte depends on this ebuild. Not sure it's a good idea because Graphyte might depend on more module, and the change in factory repo will break the Graphyte framework... Hung-Te do you have any advice?
,
Mar 6 2017
The reason that let I consider moving back Graphyte is this CL: https://chromium-review.googlesource.com/#/c/446198/ I need the persistent SSH link to speed up the testing, and I found out I need to port 6 util module... Because I had some local change after porting, the signature of functions are different. So the procedure becomes sort of painful. Or another way is: I DO NOT modified the files copied from factory repo, then I can update the files easily: just copy the latest file to Graphyte repo?
,
Mar 6 2017
We did request utils.* to be "easily imported into other projects", but not device API. I don't think we'll want to add factory utils ebuild, since that will be very painful to maintain (especially it may not include device.links.*). So the only choices are 1. move graphyte to factory repo just like instalog. or, 2. fork in graphyte and only update when you need. Do you really need whole 6 modules? Or just few functions from them? My concern is if you are not using device.links.* or utils.* in same way that other factory code is doing, it may be hard to maintain even if your code is moved back to factory repo. If we won't try to change the links very often in future, I prefer to fork and keep graphyte isolated; otherwise you can move it back to factory repo, but you'll need to find better way for its deployment.
,
Mar 6 2017
Yes, actually I already copied some of functions in these 6 modules before. But OK, I also tend to keep forking the code from factory repo before the current build ends. If porting becomes frequently and I cannot stand it, then I will consider moving back. So the current plan is to keep the source codes in graphyte/utils is the same as factory/py/utils. Then it should make porting easier.
,
Mar 25 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/vendor/graphyte-litepoint/+/b43daf8debf34585d0001122567b39581e610707 commit b43daf8debf34585d0001122567b39581e610707 Author: Chih-Yu Huang <akahuang@google.com> Date: Sat Mar 25 17:22:59 2017
,
Jul 13 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by hungte@chromium.org
, Mar 6 2017