Hi, On 28/11/14 15:23, "Patrick Ohly" <[email protected]> wrote:
>On Fri, 2014-11-28 at 12:57 +0000, Lehtonen, Markus wrote: >> On 28/11/14 14:17, "Patrick Ohly" <[email protected]> wrote: >> >On Fri, 2014-11-28 at 10:10 +0200, Markus Lehtonen wrote: >> >> Hi, >> >> >> >> Thanks for your comments. >> >> >> >> On 27/11/14 15:33, "Patrick Ohly" <[email protected]> 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. >> > >> >Which spec files will be "semi-automatically" maintained? I wasn't >>aware >> >that we had such a category ;-} >> >> It's the "spec file marked for auto-update" in the diagram. Need to make >> the description clearer on this. > >What I meant is: which of the current Tizen git trees will be in this >"semi-automatically maintained" mode? This proposal doesn't take a stance on this. Probably it would be good to start with all packages start to use the fully automatic mode in the core packages as soon as possible. The fully/semi mode would be defined in the .bb packaging meta data (in the per-pkg git repo) so it would basically be the package maintainer's call which one to use. >> The idea behind the auto-generation of .spec-related patches for the >> "semi-automatic" packages was to work as a gentle push/reminder towards >> maintaining the packaging metadata in .bb. That could be removed, if >>seen >> useless/redundant/annoying. > >I suspect that you mean packages where someone has created a .bb file >once, while others continue to use and edit .spec files. If yes, then >pushing the generated .spec for review will essentially undo the later >manual changes to the .spec file. I don't think we should do this. If not pushing an updated patch, an option would be to put an automatic comment to Gerrit that "I see only .spec was changed, you should preferably update .bb instead". What do you think? >The purpose of such a mixed tree could be to prepare the future .bb in >parallel to still building with hand-crafted .spec. But I'm not sure how >useful that would be in practice. I think it would be easier to try out >a .bb locally, then push it for review at the same time as converting >the tree from .spec to .bb. Yeah, might be. Thanks, Markus >> >The obvious downside is that meta-tizen lacks Tizen and most likely >>will >> >never be quite complete. It will be much better to maintain all >>packages >> >with .bb, >> >> Yup. But we might need to do something like that under a transition >>period >> where all maintainers are not yet using .bb. > >Exactly. --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
