[RFC] Layers for testing large features/changes (e.g. updating the device model)

[Brendan Kerrigan]

In the interest of easily creating builds to test Eric's work on updating OpenXT's device model to QEmu 1.4, I created a layer with help from Chris that can be added to an OpenXT build to include the change. Essentially I'd like to get comments on whether people think this approach to a workflow for larger feature changes is worthwhile. It has its advantages in that it is easily included and removed from a build without having to muck around lots of different repos, and cleanly shows what changes it makes to the baseline OpenXT. When the feature/changes of the layer mature to the satisfaction of the community, it's not a huge task to get it integrated into the main xenclient-oe layer. Admittedly it isn't as easy as doing pull request/merge, but merging the changes of a large feature happen only once, while one would hope testing of such large features happened more frequently. In order to encourage testing of these new features, I think it's important to make creating builds with the features as easy as possible.

The meta-qemu-1.4-oxt layer:

https://github.com/brendank310/meta-qemu-1.4-oxt 

Only change that needs to be made to include it with a build is to add it to your build/conf/bblayers.conf:

...

BBLAYERS ?= " \

...

${TOPDIR}/repos/meta-selinux \

${TOPDIR}/repos/meta-qemu-1.4 \

"

And in setup_build (around line 114):

...

getgit $REPOS/meta-selinux $META_SELINUX_REPO $META_SELINUX_TAG

getgit $REPOS/meta-qemu-1.4 git://github.com/brendank310/meta-qemu-1.4-oxt.git master

 

 if [ ! -z "$EXTRA_DIR" ]; then

...

 

[Chris Patterson]

If you have a build tree that you want to use (or already run ./do_build.sh -s setupoe), you may just grab the layer manually:
# cd build/repos
# git clone git://github.com/brendank310/meta-qemu-1.4-oxt.git

(you still need to add the layer to bblayers.conf)


I propose that we take this layer and make it part of /openxt/ as an optional feature layer until it stabilizes and can be merged into the mainline repos (then move it to the boneyard).

[Justin Bennett]

I've been managing builds internally for AIS and the SecureView program and this approach to compartmentalizing new features / major changes seems great to me.  This allows people to include or exclude new things at their discretion which should make it much easier for everyone to test out new things without running the risk of breaking the mainline openxt builds.  Once bugs have been found and cleaned up and the layer seems stable, it is pretty trivial to merge the changes back into openxt and just do away with the layer.

--
You received this message because you are subscribed to the Google Groups "openxt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openxt+un...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openxt/6978cdb6-13b1-411f-83ca-b0aaefff33b8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[eric chanudet]

I have some concerns about this approach.

First, I believe forking, even multiple repositories, is easier for
developers rather than setting up an OE layer and have to maintain a
patch-queue instead of commits (which is what was done in this case).
I know OpenXT already maintains patch-queues, so it is not harder than
that, but having the possibility to commit stuff for
backup/testing/else... and then rebase everything to make a pull
request seems like a big plus to me. I know it is doable with the
patches, except dealing with commits seems easier to me.

About the testing part, again in this case, having only a fork of
xenclient-oe.git is enough (as I said earlier, I could have pushed a
commit with the modified sub-projects recipes amended to fetch from
their respective forks and remove that commit from the merge request).
Meaning someone who wants to test the feature only has to checkout the
fork in a branch in his build tree. There is also an advantage to
that, if someone else was working on another feature conflicting or
likely to break the forked work, the fork would be safe. When either
of those feature gets merged, the other can integrate the former
without being broken by the time it happens.

--
Eric CHANUDET

[Brendan Kerrigan]

I think the issue comes with integrating with multiple features, particularly larger ones that may span across multiple repositories. I don't believe the forking/merging method provides adequate independence, especially for downstream users which would need maintain those merges across several repositories.

 

Let's say I'm testing qemu-1.4 and feature xyz.  Right now, with the approach of pointing to eric’s repos, I would have to figure out which (5?) repos are forked by eric for the qemu 1.4 feature.  Now I would need to fork those (if not already forked for my local feature(s)), then come up with a merge strategy locally to maintain within my own forks and keep in sync with eric’s (and possibly others).

 

I think the fork-it-all approach is great when you constrain yourself to one feature set at any given time.  However, downstream consumers have at least one other feature set to bring in their own changes.  Add another feature (say linux.next or xen.next or haskell_upgrade, etc.) and the permutations quickly grow.  Instead, wouldn’t it be useful to simply be able to add the respective layer to combine what you need?

 

As for development workflow, you still can source control within your personal git repo to work within (and maintain on github, if desired). For instance, with your changes to dm-agent.git, as long as you have the upstream as a remote, you can generate/restore the patch set and bbappend quickly, using git format-patch and git apply.  A small script like below can do most of the busy work.

 

Here's a script to generate most of what you need quickly (run within dm-agent repository, ./script.sh dm-agent_git.bbappend):

 

#!/bin/bash

 

mkdir -p recipe/files

pushd recipe/files

 

PATCH_FILES=$(git format-patch upstream/master)

cd ..

echo "FILESEXTRAPATHS := \"\${THISDIR}/files:\"" >> $1

echo "" >> $1

echo "SRC_URI += \" \\" >> $1

 

for x in $PATCH_FILES; 

do

echo "file://$x \\" >> $1

done

 

popd

 

From there it's just a matter of adding it to the appropriate images. 

[eric chanudet]

On Wed, Jan 21, 2015 at 11:27 PM, Brendan Kerrigan
<brend...@gmail.com> wrote:
> I think the issue comes with integrating with multiple features,

Kyle explained that to me and I mostly agree about it. It should make
things a little easier without adding too much overhead. Nevertheless
...

> I would have to figure out which (5?) repos are forked by eric for the qemu 1.4 feature.

As I said, this is merely a commit away in the xenclient-oe.git fork
(changing the source of appropriate recipes ?)... At least considering
a test build including only one testing features (like Qemu 1.4) at a
time. Since they are in-development or early testing features, I
thought trying to test more than one at a time might not be a usual
case. As it turns out, it could be.

> [...] then come up with a merge strategy locally to maintain within my own forks and keep in sync with

> eric’s (and possibly others).

In the layer approach, nothing guaranties that two features won't have
conflicts when their respective patches are applied (specifically if
the order they are applied changes from one build to another depending
on which feature is added first). Actually, in a repo, git might take
care of that, but then you have to maintain the merged features...
This is only solved with independent enough features really. I guess
it could be easier to make the integration with the layers though.

> As for development workflow, you still can source control within your
> personal git repo to work within (and maintain on github, if desired).

Indeed, I misunderstood how it worked initially.

All considered, I agree it is a better approach.

Thanks for answering my questions.

--
Eric CHANUDET

[Philip Tricca]

Great to see both sides of the meta-layer vs topic-branch discussion
playing out. Both sides have merit and developers seem to select their
workflow as much based on preference and comfort as they do based on the
appropriateness for the job at hand.

Also I'm interested to know if we're working towards a "standard"
workflow that we intend to impose on ourselves. If this is the case we
should again document this in the 'contributing' wiki page. Probably
good to document both approaches and consider the situations where
they're best applied. I'm sure there are scenarios where one just won't
work though I'm at a loss to pull an example out of my ... hat.

Great ideas all around. Anything that makes testing new features /
upgrades easier is a net win.

Best,
Philip

[Philip Tricca]

Hey Brendan,

I followed your instructions for building the qemu-1.4 stuff the other
day. Thanks for putting these together. Thought it might be useful to
have them up on the wiki so I did some editing:

The updated page is here:

https://github.com/OpenXT/openxt/wiki/QEMU-Upstream

The diff with my changes is here:

https://github.com/OpenXT/openxt/wiki/QEMU-Upstream/_compare/60529db5a8d09f94b9dad661fa654dc5f90ac797...6f1ff86b9c9e6db8b3fd647771a46f4cc300c514

If I did anything too terrible feel free to make corrections.

Thanks,
Philip

> --
> You received this message because you are subscribed to the Google
> Groups "openxt" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openxt+un...@googlegroups.com

> <mailto:openxt+un...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openxt/3fab063b-7be1-4640-bdf6-5288fb9412f2%40googlegroups.com
> <https://groups.google.com/d/msgid/openxt/3fab063b-7be1-4640-bdf6-5288fb9412f2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Chris Patterson]

Thanks Phil for updating the docs, those directions look good to me.