On question #1 ... a bit of context from JON .... the future direction is to
* decouple plugin release cadence from JON
* couple the plugin release with the respective middleware
This way ... we will be able to release what is now referred to as "core JON"
separately ... and the plugins will be released in cadence with the respective middleware.
I believe this to be the correct coupling.
I suppose one could argue that how the repos are organized is an implementation detail;
but, I think you are correct in inquiring about the optimal dependencies and couplings
here. The repos and build scripts ...do tend to begin to impose a coupling. I am
particularly interested in learning more about the evolution of your thought process in
this paragraph
I personally was a proponent of a more granular split to even more
repositories than just plugins, helpers and the rest. But since then I've come
to the realization that what I really meant was more loose versioning scheme
of the individual components inside RHQ - and this does not necessarily
require standalone repositories - those would only make the "point" of
separate release cycles stronger.
Mike
----- Original Message -----
From: "Lukas Krejci" <lkrejci(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, February 12, 2013 2:24:39 AM
Subject: Re: github migration
While technically, I think we have most of the questions answered thanks to
your work, Heiko, I think a couple of questions still have to be answered.
1) If we are going to split plugins and helpers from the core RHQ, how is it
going to affect versioning?
Are we still going to require "simultaneous releases" of all the plugins and
the rest of the RHQ? Or are the plugins going to "have life of their own"? If
there is just one repo for all plugins, are all the plugins going to have the
same release cycle or is each plugin going to be versioned separately? If they
were versioned separately, wouldn't it make more sense to have a repo per
plugin?
2) Our goal is to improve the situation of the plugin writers so that they
don't have to check out the whole codebase before they can write their own
plugin (which they don't have to do even today). How is the split of the
plugins going to help them? They can depend on a released plugin-api artifact
and create their plugin in a complete separation from the rest of the
codebase.
None of these questions, I think, is a blocker for the move but given the fact
that the chosen answer might affect the way we organize the repos, I think it
is important to at least rule out some of the options before we make the move.
I personally was a proponent of a more granular split to even more
repositories than just plugins, helpers and the rest. But since then I've come
to the realization that what I really meant was more loose versioning scheme
of the individual components inside RHQ - and this does not necessarily
require standalone repositories - those would only make the "point" of
separate release cycles stronger.
So in another words I think we need only a basic idea about our future
versioning strategy for at least the plugins that just call for individual
release cycles. Once we have this (rather philosphical) question answered, I
don't think there is much that holds us back from the move. It'll be just a
tedious excercise in flipping all our dev environments, CI jobs and various
other internal Red Hat tools to use the new URLs.
(Btw. what about the platform plugin? Shouldn't that be really part of the
core? I know that people can roll their own but how many do that? And given
the fact that none of the other plugins would be functional without platform,
wouldn't it be more logical to have the platform plugin as part of the core?)
Cheers,
Lukas
On Monday, February 11, 2013 17:22:17 Heiko W.Rupp wrote:
John,
very good question.
Am 11.02.2013 um 17:01 schrieb John Sanda:
> Where do we stand with respect to the github migration? What outstanding
> tasks are left before we can pull the trigger? Given that we have various
> RHQ and JON releases in flight, when is the best time to make the move?
Actually I think we have an almost perfect timing now. Perhaps get RHQ 4.6
out of the door and then after this, migrate over. This leaves us enough
time for RHQ 4.7 and the next JON release.
I think we should when doing that
split off
- plugins
and
- helpers except rtfilter*
Heiko
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel