On Wed, 2012-03-14 at 07:45 -0700, Darren Hart wrote: > On 03/13/2012 09:12 PM, Bruce Ashfield wrote: > > On 12-03-14 12:05 AM, Darren Hart wrote: > >> > >> > >> On 03/13/2012 08:08 PM, Bruce Ashfield wrote: > >>> On 12-03-13 11:03 PM, Tom Zanussi wrote: > >>>> On Tue, 2012-03-13 at 22:40 -0400, Bruce Ashfield wrote: > >>>>> On Tue, Mar 13, 2012 at 3:44 PM, Tom Zanussi<[email protected]> > >>>>> wrote: > >>>>>> On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote: > > ... > > >>>>>>> I believe crownbay no longer requires special patches right? Can we > >>>>>>> just > >>>>>>> use the standard/default/base branch here and squash the crownbay > >>>>>>> branch? > >>>>>>> > >>>>>> > >>>>>> At the moment it doesn't, and I'll probably submit a patch to do that > >>>>>> for everything that it make sense for again after things are functional > >>>>>> with the simple changes first. > >>>>> > >>>>> There's one catch with this. We currently have the graphics drivers > >>>>> staged as > >>>>> topic branches so they can be in tree, and be kept pristine. The BSPs > >>>>> merge > >>>>> the graphics topic branch they want, and we can leverage common commits > >>>>> across all the users. > >>>>> > >>>>> If you drop the BSP branch, then the graphics changes need to be > >>>>> universally > >>>>> safe for all similar BSPs, since that merge will now be to a shared > >>>>> branch. > >>>>> That's normally fine, but for the case where we have multiple emgd > >>>>> versions, > >>>>> it can break things. > >>>>> > >>>>> We have complete flexibility to how we stage the branches, and how we > >>>>> generate the content that is built, so this can change .. but that's > >>>>> how we currently > >>>>> have it setup. Those graphics merges are board specific changes and > >>>>> require > >>>>> a branch. > >>>>> > >>>> > >>>> That's fine, I'm perfectly happy to have per-BSP machine branches. > >>>> They're cheap, and I don't really see the reason to be so parsimonious > >>>> with them. Also, they're always there, so if we do need to have a place > >>>> to put the odd machine-specific patch now and then we don't have to add > >>>> a new branch when we need to add those patches, or remove them once > >>>> they're gone. I guess the system was kind of designed for that (machine > >>>> branches, even if empty)? > >>> > >>> Exactly. We can collapse them where it makes sense, and keep there where > >>> we need them. A machine branch is just that, a topic branch for > >>> development > >>> and implicit documentation of a supported board. If a board may be > >>> extended > >>> in the future .. a branch is nice to have. > >>> > >>> I'm in favour of keeping the count in control, but see no need to collapse > >>> them down completely. That and I spent an hour trying to figure out > >>> how to do some fancy merge logic and while it could be done, it just > >>> makes things more complex. I'd prefer branches to overly complex > >>> branch management logic. > >>> > >> > >> Agreed on the concept. What I'm not understanding is how is having to > >> get yocto/emgd-1.10 to merge with standard/base any different than > >> having to get it to merge with: > >> > >> standard/default/crownbay > >> standard/default/common-pc-64/sugarbay > >> standard/default/fri2 > >> > >> etc. > >> > >> emgd isn't premerged into these machine branches if I understand the scc > >> files correctly, so how is this any different? (I'm sure it is, I trust > >> you here, I would just like to understand what I'm missing). > > > > When a tree is built from scratch (from the meta data + patch repo), or > > when BSP validation runs across a tree. All BSPs are constructed in a > > single tree. If you have merges into common branches, the third, fourth > > or fifth one is going to eventually explode. > > It seems like the obvious answer here is to always create a machine > branch during tree construction if one does not already exist. This > would address the concerns of automated bulk validation while still > keeping the branching in the git tree to a minimum. Very few users will > be manipulating the git tree in the WORKDIR, and those that do are > expected to be advanced git users that can run: > > $ git cherry standard/base > > So why do I care about keeping the branch count down? > > o It helps make it explicit where we have deviated from mainline. > - Clear visibility into this is one thing that users have > complained about. > - It maintains the 1:1 mapping between branches and actual source > changes we've discussed. > > o It encourages people creating new BSPs to use an existing branch > if at all possible. > - We can encourage people to do this, but unless it is clear we > are following this advice ourselves, others will not follow. > > Taking a hard line on this is also part of boiling down our language and > firming up policy and tool definition. Doing so makes things more clear, > easier to learn, understand, contribute to, as well as maintain and debug. >
In principle, I agree. The main thing I don't like about it is the potential there is for ping-ponging between having to add a branch because we have a single BSP-specific patch and then having to remove that branch again when it goes upstream or is no longer needed. Users can use standard git queries to find out whether a machine branch currently has anything that differs from its parent - I'm not sure counting on the existence of a branch as a quick indicator that it deviates from mainline is really all that useful for users, but maybe it is. In any case, it's a minor point and in the end if it makes things easier for users, that trumps everything else... Tom > -- > Darren > > > > > > That being said, I *can* inhibit the merges during tree construction and > > only do it when individual boards are built. But in that scenario, we miss > > an opportunity for automated/bulk validation that the merges are safe > > and valid. > > > > So your observation is correct, and it's just a use case of the descriptions > > > > That's why I mentioned that we can collapse them, but there is an increase > > in complexity. Something to keep in our back pocket, since it's there > > to use when we need it. > > > > _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
