github migration

Lukas Krejci lkrejci at redhat.com
Tue Feb 12 07:24:39 UTC 2013


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


More information about the rhq-devel mailing list