On 12-03-14 4:40 PM, Darren Hart wrote:
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.
+1 .. and I forgot to type in my last email, that all of the points I
mention are minor, so really, with the right tweak .. I think this is
a fine idea.
Cheers,
Bruce
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
