github migration

Heiko W.Rupp hrupp at redhat.com
Tue Feb 12 08:15:01 UTC 2013


Hey Lukas,

good points

Am 12.02.2013 um 08:24 schrieb Lukas Krejci:

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

My proposal is that they work against a *stable* version of RHQ core.
E.g. the current 4.6-snapshot stream would work against 4.5.1 artifacts.
If the plugins need a newer version of modules/core, we would build
a new stable version of that and publish to central.
The important point here is that those modules/core artifacts (and perhaps
also dependencies for server plugins) are available from central so that a
plugin developer does not need to add some jBoss repos to his setup 
in order to be able to compile them.
Another possible, but imo less desirable alternative is to publish timed
snapshots ("versioned snapshots"?) to central. We should do that only
when relevant changes are made and not on a per run or nightly basis, 
as this would just pollute cental (and would probably be rejected anyway).

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

I think this is too much, as GITs version of "pull many repos into an über-repo"
is less powerful than what we had with svn the old days. But you mention
an important point below: we should indeed define a core set of plugins 
(platform, jmx, ... ) that could stay in the rhq-core repository.

> 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.
> 
Yes, that is the idea. To reiterate what I said above, it is important to create
dependencies that can be made available on maven central, so that users
don't have to first modify settings.xml or do other tricks to get this going.
Yes, one could add the JBoss-nexus to the plugin poms, but I doubt that
the JBoss nexus would be happy with snapshots after each little checkin
somewhere in our code base.
> 
> 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.

In an ideal world we would split out modules/core into its own repo
and have the other repos depend on stable versions of modules/core

But again, as git does not handle pulling from many repos into one
über-repo that well, I don't think that is really desirable from the workflow.

The helpers depend on modules/core but other than that are pretty
loosely coupled with RHQ, so that the versioning is less of an issue there.

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

For the dev environments, I'd say that people push what they have to FH
and then after the migration clone the new GH repo into a different 
directory. This allows to still fetch from the local clone of the FH repo (e.g.
for work in branches). 

> 
> (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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-- 
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, 
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer:  Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130212/6a647bb3/attachment.sig>


More information about the rhq-devel mailing list