Starting a new thread to consolidate some thoughts in the other
two threads...
After reading through the github migration threads and wiki, I
see it actually involves a few different things:
- The actual migration.
- Proposed pull-request workflows.
- The split to multiple repositories.
- Versioning schemes.
The actual migration plan is detailed and Heiko looks to have
done a good job of mapping out the details of how it will
happen, including a dry-run.
The new workflows look promising, especially from a code-review
perspective. I think we'll need that written up more formally
for ourselves and contributors. And maybe have a good demo for
the team so people (like me) get a good grasp of what we'll be
doing. These processes are also something we can modify as we
go.
I'm OK with the idea of breaking RHQ into 3 pieces, core,
plugins, and helpers. I think it will be helpful to plugin
developers to potentially work with a smaller codebase, and a
clearly identified helper project. I also think the decision
to avoid further granularity is a good one. We will need to add
some Jenkins jobs, but I don't think it will be an unmanageable
number (it's not 3 times the number we have today). And we will
likely need to update our release processes, again. Keeping the
platform plugin in core makes sense so that core can actually
run on its own, and also for anyone that plans to use only
custom plugins.
It's the proposed dependency versioning that I'm questioning.
I'm not convinced there is real benefit to plugin writers or
contributors by having rhq-plugins/master depend on a released
version of rhq-core. In short, what's wrong with instead asking
the developer to git checkout rhq-plugins/release-X rather than
rhq-plugins/master?
A plugin developer does not need to build rhq-plugins/master to
develop a new plugin. On the other hand, rhq-helpers/master,
plugin-gen in particular, would benefit from depending on
released artifacts. In that case the plugin dev could build the
generator easily, against deps published in central, and run a
real server/agent of the same version, installed from product
dists.
As for working on an existing plugin; an enhancement or bug fix
could be built against rhq-plugins/release-X.
Rhq-plugins/release-X is easily built against central. The
feature or fix would be compatible with the published version of
core.
Using 4.6 as an example, if we had an rhq-plugins/release-4.6
branch, a developer could opt to build this branch against the
published artifacts, and make a fix or enhancement to the 4.6
plugin. Work committed here could be cherry-picked to master as
needed. If in fact the developer or contributor elected to work
with master they certainly could, in the same manner as today,
by building rhq-core/master and working with the snapshot
version.
As a further example, let's say someone finds a bug in the 4.6
AS7 plugin. It could be fixed against rhq-plugins/release-4.6
by anyone, without having to build core. It could also be fixed
in rhq-plugins/master with a full dev environment, and
cherry-picked back. And rhq-plugins-4.6.1 could be released
without a need to release a new core/server.
The current proposal on the wiki is to have rhq-plugins/master
depend on rhq-core's current release version, and not on
rhq-core/master's snapshot version. This will certainly make
development more difficult. One immediate example will be the
new provisioning implementation. This feature development will
involve new facets, change to the plugin descriptor, and
introduce other dependencies between plugin code and the [core]
container. A strategy that forces the plugin code to conform to
rhq-core's release version will make this very hard.
Let's talk a bit about plugin/core compatibility. As it stands
today (I believe) an agent plugin can be dropped into an RHQ
server, and we don't really validate it, we assume that it is
compatible. Assuming the plugin descriptor parses, and metadata
updates succeed, we're good on the server and the agent is free
to pull it down. It's pretty loose. That doesn't really have
to change. Plugin release cadence is not really dependent on
rhq-server version. It simply has to be compatible. Developing
against a release version will give you that and (unless using
deprecated features that are going away) will give you
compatibility with the next release. But, to ensure timely
release of a plugin leveraging new features of core, it must be
easily developed against core's snapshot version. To prevent
this will make things difficult, likely force unnecessary core
releases, and create lag times between core and plugin releases.
The benefit of being able to check out and build
rhq-plugins/master without needing to also build
rhq-core/master, does not seem to be enough to merit the
downside to plugin development and release.