On 03/14/2012 01:25 PM, Bruce Ashfield wrote: > On 12-03-14 10:45 AM, 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 > > That can be done .. and I've done it in the past, dynamic branches > are supported within the tools. But there are always issues: > > - anything dynamic is never as smart as someone specifying a feature > description and deciding whether or not they want a branch. I've > nearly always regretted dynamically creating branches in the past. > > - It's not just machine descriptions that trigger merges, any feature > can have one if it has a topic branch that is being maintained in > that manner. So I tread carefully here to not introduce special > cases. We are talking about a known optional, board specific merge. > A human can make that call pretty easily and specify that they > want a branch. > > - Some people just like to build the branch that they want to build. > Since, for example, they might be pushing changes onto a non > machine specific branch and expecting it to build .. and sometimes > that branch isn't even the parent branch (i.e. some temp build). It > also means that working in the build tree patches don't have a 1:1 > home in a source repository. But there are other things that make > this a non-ideal workflow, so I don't really mind making it harder :) > > That was the whole intent of KBRANCH. You specify explicitly what > you want to build, and the system lets you build that branch. This > means that you'll build the same content .. but maybe not that > branch. > > - Tree generation would have to dynamically create them, and then > remove the non-static branches when it completed. Completely doable, > but with a complexity cost. Complete tree generation and per-machine > building would now differ (although minor). > >> 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. > > There are far worse examples of non-obvious branches out there, but > I don't disagree with the principle. > >> >> 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. > > I don't really have big problem with people working on machine branches :) > It's just a topic branch that holds work, it's like anything you do in > a git repo .. do it on your own branch .. and then merge it back. > > Anyway, I'm making changes to quite a few things right now in the tools, > and we don't want to do this for 1.2, so let me think about this for a > day and see if any other use cases break. >
Yes, let's revisit after 1.2 is out. Not need to muddy the waters with it now. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
