Export ConfigurableComponent in service xml

[ctron]

Signed-off-by: Jens Reimann jreimann@redhat.com

[ctron]

This should be backported to the 2.1 release branch

[amitjoy]

👍

[dwoodard1]

@ctron Is there a reason you wouldn't just rebase against the release-2.1.0 branch? Not sure if you had a cleaner approach in mind for backporting.

[ctron]

AFAIK development goes on in the develop branch. And you can easily cherry-pick those commits.

[dwoodard1]

Historically, once the release branch is created, we make all PRs that are to go in the next release against that branch. Once the release is done, we merge the release branch back into develop. I am not saying this is the best way, but it is how we have typically done releases. My only concern with the cherry-pick approach is for PRs with multiple commits. Seems that this leads to potential user (i.e. me) error.

[MMaiero]

I agree with @dwoodard1: if changes have to be applied to 2.1, why not having related PRs to point to 2.1?

[ctron]

So I'll just squash it then.

The problem with this approach is that this will fragment development even further. Because this results in having additional branches of each upstream branch. And if the change is not accepted, which takes mostly several weeks to figure out, then I need to rebase in the develop branch, again.

Issuing PRs on the release branch and cherry-picking the other way round seems strange to me.

The normal flow I know is to fix the issue in develop and then back port (cherry pick) it into the release. Which I think is also to model of gitflow?!

[ctron]

@MMaiero changes have to be applied to the release and develop.

[MMaiero]

@ctron I understand, but if we apply the changes to the release branch and then we merge it into develop, don't we obtain the desired effect? The release branch, in any case, has changes that need to be merged in develop and the two branches will be aligned until the effective release of Kura and subsequent update of version in develop. Or I'm missing something?

[ctron]

So if the change needs to be in both. Why not apply it to 'develop' and then cherry-pick that change to release?! Cherry-picking is a fine grained operation, and so the change can be made available on develop right now, work can go on and the cherry-pick operation on the release branch can be done in a controlled way.

Working on another branch, with another set of PRs would mean that I would need to again switch all of my branches to "release" and replay all still un-merged changes into my testing branch, forked from Kura.

[MMaiero]

We can do the cherry picking.

But if the change is self contained, you should be able to create a pull request of them and point it to either develop or release without needing to manage with branches and where they come from.

[dwoodard1]

For this release, let's try and continue using PRs against the release branch when possible. For this PR, we can cherry pick. We can discuss the best approach for future releases on our weekly calls. I will merge this and cherry pick later today.

[dwoodard1]

Merged into release-2.1.0 branch: b70e63c