Hi, On Wed, 2014-12-03 at 18:53 +0100, Dominig ar Foll (Intel OTC) wrote: > Hello, > In the proposed wiki page for Tizen Distro Workflow > https://wiki.tizen.org/wiki/Tizen-Distro_Workflow > > I would like to open the discussion on the specific issue of maintaining > Tizen evolution and resynchronisation with newer release of Yocto. > > 1) Source code sync seems covered > ----------------------------------------------- > My reading is that for the majority of our work which is modifying code, > the process covers the need. > The code would be changed in git which is reviewed in gerrit and > triggers a test build in a Yocto buildbot and then a build in an OBS. > Code is unique but shared by the two build systems. > > "only tricky" cases will be induced by code which will build on one > subsystem and not on the other. > So far, I am happy to assume that is will be rare. > > 2) A change is required in the Meta-data > ---------------------------------------------------- > For any reason a change is required in the building meta data, new > dependency, special case to support and architecture, ... > In reality those changes are not frequent but do occurs. > > I would like to better understand your proposition. Could you please > confirm or reject my understanding and explain better what is your > proposition if you feel that I missed the point. > > A) The developer should do a modification on the Yocto side (bb files/ > layers) as the OBS side (spec) are generated automatically from the bb > files/layers.
The proposal would allow for packages to not have automatic conversion from bb to spec. Allow developers to maintain the the packaging information in .spec for a transition period. At some point, automatic conversion would be used for all packages. In the other thread with Patrick we had discussion about this. Periodic check/sync of the packaging metadata of these packages would be needed for the transition period. > B) Should the developer always create a bbappend file to contain his > changes or can he patch the bb files directly. > Note the later is far easier for him but make the realignment with the > next revision of Yocto would be become more complex. > Could you explain your vision on the process when a realignment with > Yocto will be required. All Tizen-specific modifications would be in Tizen-specic layer in tizen-distro. IMO, using bbappends would be the (strongly) suggested way to modify oe-core packages. Bb files only to be used if absolutely necessary. Re-alignment with oe-core (or any other "upstream" layers) would be something like: 0. In a staging environment... 1. Pull patches from upstream layers 2. Find orphan bbappend files (i.e. for the cases oe-core has done version bump but Tizen's bb points to the old version) 3. Rebase orphan bbappend files 4. Run test build and fix problems 5. When happy, merge the changes. This wouldn't be automatic, but done in controlled manner by the distro maintainers. > C) In your proposal, the bb files would be associate to each package in > Tizen what is different from the traditional Yocto unified model. > How the developer will have a view of all the meta data affecting his > package in order to propose a change from that reduced vision ? I think that in order to effectively work with the .bb metadata the developer needs to use the tizen-distro combined repository. There will be a helper tool (supposedly git-buildpackage) that helps working with the tizen-distro and per-pkg repositories. Good that you brought this up because I need to add a proposal of the helper tool to the wiki, too. > > > D) How do you propose to handle changes which would spread over multiple > packages which are managed in the project conf on OBS. Where will that >code reside ? How will maintain it ? What about future >realignment with new Yocto release ? What do you mean by multiple changes managed in prjconf? Changes to multiple packages at the same time would be handled as group submissions like now. I think the distro configuration in meta-tizen would correspond to the OBS project conf. Conf in meta-tizen would be maintained via Gerrit. >E) The layers are by nature covering the building of multiple packages > for most of them. Where will they be maintained for Tizen ? Who will be > the maintainers ? The proposal states that package metadata of the layers will be automatically synced from per-pkg repositories. Other data (classes, conf,...) will be maintained through Gerrit review. Probably the maintainers of those would be architects and release engineers, similar to OBS prjconf et al currently. > > F) In the rare case where the package will build under Yocto but will > fail on OBS, what will be the tool for the developer to help him to fix > the issue knowing that the spec file is generated from the bb files ? The first thing is of course to look at the spec file and build error. At the moment, other than that I can only think about gbs local build. > > Thanks in advance for your clarifications. > Thanks for your questions. I hope my answer shed some light over the subject. Obviously, there still are murky and unresolved questions and the whole setup is complex. I will update the wiki page based on the comments from you and Patrick. Thanks, Markus _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
