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

[Khem Raj]

On Tue, Oct 2, 2012 at 11:45 AM, Jerrod Peach <peachj at lexmark.com> wrote:
> 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?

well if machine is same then it should be so. But you can have
different images meant for same image. e.g. image-printer1
image-printer2 etc. however this may not be best if you want two
different versions of same package X in those two images. You could
also look into package groups and IMAGE_FEATURES. I think if you need
to put two different revs of same package then branching may be better
approach or you could have multiple recipes X-printerA.bb
X-printerB.bb
and so on and chose the right one into image-printerA and so on.

There are many ways you can use. You have to look into what fits best
to your needs


>
>>
>> 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
>
>
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>