github, restructuring and versioning

John Mazzitelli mazz at redhat.com
Thu Mar 7 17:10:57 UTC 2013


> 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.

I agree. And its not that big of a deal to ask plugin devs (if they don't want to build all of core) to simply git checkout the plugin repo's release branch (rather than just stay on master).

So, all they would need to do is, after a clone, do the extra (but extremely simple step) of just checking out the release branch. (git checkout release-X).

This leaves the plugin repo's master branch to follow the core repo's master branch.

If we don't do this (but instead rely on plugin repo's master branch to be dependent on the core repo's release artifacts) its going to be harder to develop new plugins in the master branch or fix existing plugins to work with the new core (i.e the master builds) - especially when new features to plugin API is added (which is going to happen with the provisioning stuff).

It just seems to make more sense and is more intuitive to have a release branch in plugins repo to be dependent on release artifacts from core. This frees up master branch in both to move ahead quickly.

My other question would be - if the plugin repo's master branch is dependent on the core repo's release branch, where (in what branch of the plugin repo?) do I develop plugins to work with the core repo's master branch?

----- Original Message -----
> 
> 
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list