github, restructuring and versioning

Jay Shaughnessy jshaughn at redhat.com
Thu Mar 7 17:01:58 UTC 2013


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.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130307/ec7d3743/attachment.html>


More information about the rhq-devel mailing list