Tomas, On Wed, Oct 3, 2012 at 3:59 AM, Tomas Frydrych <tf+lists.yo...@r-finger.com>wrote:
> > 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? > > I would agree that in this scenario it would best to maintain the source > revisions in the bb recipes themselves, it keeps people rom stepping on > each others toes and accidentally changing revisions for other packages > (which is easily done in automatic merge-conflict resolution gone wrong). > Okay, so it sounds like my game plan should be to tag my metadata and branch it only if necessary, i.e. if someone needs to change a BB file. (That makes sense, of course, but we have had a long, storied history of branching when it wasn't necessary in our build and library system, so that is a change for us.) Even if we branch our metadata, we'll be creating a new tag once whatever modifications we need have been made. Can anyone see a better way to handle releases than that? Kind regards, Jerrod
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
