It was <2014-11-28 pią 12:18>, when Patrick Ohly wrote: > On Fri, 2014-11-28 at 08:52 +0000, Counihan, Tom wrote: >> I think some words on how the workflow from an external consumer would >> be beneficial? >> I understand we cannot be prescriptive, as each may have different >> internal workflows, but which might be interesting is does the model >> place any constraints on their workflow? Maybe there is none. > > First, let me point out that we currently don't have a good story for > someone taking Tizen and modifying it for their purposes. > > One approach is to use "gbs build" locally. [...] > The other approach is to setup a stock OBS instance and import the Tizen > project from build.tizen.org. [...] > > This is where "Tizen on Yocto" comes in. To me, the main reason for it > will be that it will enable anyone to clone the Tizen packaging meta > data and build a potentially modified image on a Linux box with minimal > requirements for prior system setup (essentially just a compiler, make, > Python). Yocto also has extensive support for common release activities: > * license checking > * publishing source > * creating an SDK > * archiving the distro build environment > > As discussed in the other thread, neither "gbs build" nor OBS go away, > so those options remain for someone who wants to go down that path. But > IMHO using Yocto instead is the better alternative.
This sound's nice and I may even see yocto usefull when I want to build an image with an update package that a lot of other packages depend on (e.g. systemd), gbs can't handle that. And I think it's cool yocto can. As long, however, as Yocto as an alternative tool does not force us to slow down or speed up Tizen development. The tail must not wag the dog. Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpRIhG3BZZH8.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
