Re: [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-10-20 at 16:36 +0200, Martin Jansa wrote:
> On Thu, Oct 20, 2011 at 03:25:52PM +0100, Richard Purdie wrote:
> > On Wed, 2011-10-19 at 16:33 -0700, Saul Wold wrote:
> > > On 10/19/2011 12:00 PM, Otavio Salvador wrote:
> > > > On Wed, Oct 19, 2011 at 16:30, Khem Raj<raj.khem@gmail.com>  wrote:
> > > > ...
> > > >>>>> Many upstreams we can't track if updates are required automagically, so
> > > >>>>> we
> > > >>>>> need a place to record when the last manual check was, also possible
> > > >>>>> reasons
> > > >>>>> why we should not update to newer versions, ...
> > > >>
> > > >> hmm manual check means it has to be done manually is there any thing
> > > >> that needs it ?
> > > >>
> > > >> I think unless they are distro specific which seems not since they are
> > > >> in oe-core
> > > >> they could exist in recipes  thats my opinion.
> > > >
> > > > I agree that this should be put into the recipes. Besides this allows
> > > > for checking if it was updated when the version has been updated.
> > > >
> > > > If done right, when updating the version this data will be updated
> > > > together. I see no change in the amount of changes.
> > > >
> > > > A plus of this choice is it will be more difficult to forget to update
> > > > that info. This happened in last qt update for an example.
> > > >
> > > 
> > > This may need to be something that the TSC brings up, possibly we can 
> > > talk about it in Prague next week.
> > 
> > So just to give some background here, the information in those files was
> > added by Yocto people to give some idea of the update status of various
> > recipes. This included when the version was last checked/updated for
> > recipes which we can't automate that process for, when certain cleanup
> > checks were made, what the general state of the recipe was and who on
> > the Yocto team was specifically looking after given recipes.
> > 
> > When it was discussed, some of it was Yocto specific, some of it wasn't
> > and popular opinion was against it going into the recipes themselves. I
> > was ok with that given we have the pn- overrides and can handle the
> > problem that way just fine.
> > 
> > OE-Core happened and we kept the data with OE-Core at least for now. We
> > have several options:
> > 
> > a) Keep the data where it is
> > b) Merge the data into the recipes
> > c) Move the data out of OE-Core
> > 
> > Since a lot of that data is fairly Yocto process specific, it may make
> > sense to move it over to meta-yocto...
> 
> I don't like "global" files where many people should maintain their info
> and it's so easy to forgot when it's somewhere else then real changes
> (like it was with checksums.ini and sane-src*.ini).

Some data does make sense to be maintained globally and I don't think we
should automatically say its bad. It depends what the use case is and
how its intended to be used.

> So I vote for b) Merge the data into the recipes, only problem with this
> is that if we have 2 versions of foo (foo_1.0.bb, foo_git.bb) without
> any foo.inc, will we create foo.inc just for distro-tracking info? Maybe
> we should and move at least DESCRIPTION and similar variables too.
> 
> c) moving it to meta-yocto will probably make distro-tracking info even
> more outdated as sometimes different people then who did upgrade in
> oe-core will have to update distro-tracking info in this layer (this is
> also the case now sometimes, but with distro-tracking info in recipe we
> can try better to update it with upgrades).

I'd actually like Saul's view on this since he generally looks after
that data. There as been discussion about whether it is "internal" yocto
tracking stuff or whether its more general OE focused and I don't know
what the answer is there. I think there is a mixture of uses. I'm also
wary of "pushing" Yocto policy into OE which I think this might amount
to.

As a specific example, we've moved away from wanting MAINTAINER info in
the recipes in the past and this gets us back there again. I don't
really want to loop over adding data and then removing it again
repeatedly so this needs thought/discussion. Who gets their name in the
MAINTAINER field exactly? What is the process for that and what
responsibilities does that person have?

Cheers,

Richard