Hi, Thanks for your comments.
On 27/11/14 15:33, "Patrick Ohly" <patrick.o...@intel.com> wrote: >On Wed, 2014-11-26 at 16:02 +0100, Dominig ar Foll (Intel OTC) wrote: >> The infra team has taken the time to document a model proposition and >> would like to get all the feedback possible. >> https://wiki.tizen.org/wiki/Tizen-Distro_Workflow > >Before diving more into it, let's clarify some points: > >What does "the above automation" refer to in the last section? Just the >"Syncing of external repositories" or everything? Ah yes. It refers to the syncing of external repositories, e.g. oe-core. >In the "RPM vs. BitBake packaging meta data" section, can you clarify >which meta data can be edited manually? It just says "packaging updated" >and it does not become clear which one that is. But as the flow diagram >always ends up modifying the .spec file, I assume that only the .bb data >may be edited. What happens when a change gets committed with >modified .spec? There would be a distinction between "fully automatically maintained" spec files and "semi-automatically" maintained spec files. For the fully automatic case, spec metadata would be auto-generated and pushed to git on every ref update, effectively overwriting any manual changes. In the semi-automatic case there would be no automatic push to the branch but a patch would be submitted to gerrit, instead. This would allow some maintainer control (with a risk of some meta data divergence, unfortunately) and not force to use bb metadata outright. The distinction between the fully/semi automatic would be defined in the bb metadata of the package. Thus, changes to .spec file are not explicitly denied (I don't even know how to implement something like that) but changes might get automatically overwritten (for the fully automatic packages). >Before people on the list get concerned by these questions and draw >wrong conclusions, remember that it will be a per-package decision how >the package gets maintained. The initial goal is to convert those >packages that we haven't modified much in Tizen anyway and already are >maintained by the core distro maintainers. So the number of developers >who really need to get used to the new workflow will be small - at least >initially. > >Long term we'll see how useful the new workflow is. Yes, the core packages are a good first target. Best Regards, Markus Lehtonen _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
