[yocto] How do you release distros produced with Yocto? How should I?

[Jerrod Peach]

Tomas,


> Sounds to me like your situation implies a single distro + multiple
> machines, one for each distinct printer model; you can then specify
> revisions on per-machine basis.


I don't think that's actually what we want.  The architecture of each
machine will be the same.  That is, one ASIC will generally be on all the
printers in a family of products.  I think I actually have one machine +
multiple distros.  Or, should I really be counting each different printer
as its own machine?


> Whether you specify the machine specific
> revisions in the bb files, or whether you pull it together into an
> include file is a matter of taste more than anything else I suspect, as
> long as everyone knows what the deal is. But I'd advise not to specify
> package revisions local.conf, that's really for the developer/user to
> tweak, and it should not be stored in vcs, doings so just causes pain.
>

That's something that's come up in our side conversations here: local.conf
is really for developers to tweak.  I will try to take care and not use
local.conf for such a thing, and I will not store it in a VCS unless I can
think of a really compelling reason to do so.  Thanks for the advice there.


>
> I use the unified include file in Guacamayo for the packages that we
> maintain; this is for convenience, as during the development cycle I use
> AUTOREV for these packages, but for an actual release specify the
> revisions explicitly and having them all in one place makes this easier
> to do and not forget anything. See,
>
> https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/conf/
> for how we got it set up.
>

So, to me it looks like you're using conf/distro/guacamayo.conf to set
those revisions.  That seems like that might work when there's only a
handful of revisions to set.  However, we'll likely have at least a hundred
packages for which we need to set/manipulate revisions.  I would think that
would get cumbersome, and in an organization the size of ours (500 or so
developers across two sites), there's not really going to be one person or
team who knows what should go in that file for a release.  Moreover, that
still leaves the problem of all those developers needing to know there are
at least two places in which their package revisions may be controlled.  Is
your organization significantly smaller than that or are we doing something
wrong?

Kind regards,

Jerrod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20121002/fbb4dc1c/attachment.html>