GitHub migration again -- The Plan

Lukas Krejci lkrejci at redhat.com
Tue Mar 5 16:04:41 UTC 2013


It seems to me you ask questions common to any modularized environment. If 
module A depends on module B and B requires a new feature/bugfix in A, how do 
you make sure that A works before B can consume it?

Essentially we've historically developed RHQ as if it was a monolithic 
codebase - hence the single repo for everything and "simultaneous releases" of 
individual components in RHQ. The move to a more modular approach to 
development itself (not only to the resulting artifacts) we are admitting to 
the true nature of the system and as a consequence we invite outside 
contributors to an easier integration/contribution experience. The contributor 
doesn't have the expertise nor time to get their head round the whole RHQ 
codebase. Factoring out the piece of the codebase that the external 
contributors are most interested in is a good thing.

Given the overwhelming success of component-based development model I'd argue 
that the problems you outline (and I agree with you that they are valid) don't 
generally manifest themselves in reality in any serious manner (and if they 
do, it is not the methodology to blame, it's usually a PEBKAC type of issue ;) 
).

See inline for more concrete comments...

On Monday, March 04, 2013 11:30:39 Stefan Negrea wrote:
> ----- Original Message -----
> 
> > From: "Heiko W.Rupp" <hrupp at redhat.com>
> > To: rhq-devel at lists.fedorahosted.org
> > Sent: Friday, March 1, 2013 8:10:49 AM
> > Subject: Re: GitHub migration again -- The Plan
> > 
> > Am 01.03.2013 um 14:20 schrieb Thomas Segismont:
> > > With split repositories, for this particular case, I would like to
> > > be able to make one commit to the core, make a minor release and
> > > then update the plugins in other commits to their respective
> > > repositories).
> > 
> > Right.
> > 
> > And then there is no need in this case to immediately create a new
> > release/timed snapshot, but your change in the plugin code can be
> > stashed
> > for a few days. This would allow to batch up changes and prevent
> > churn in the modules/core releases.
> 
> I am not sure how this would work from the perspective of getting a build
> out for testing purposes. The fix for core might break something else in
> the plugins space but there is no way to get feedback for the change in
> core until post-release of core itself. Since the test driver in this case
> would be a change or new functionality in a plugin, nothing can be tested
> with just a core release. The only way to test the change is to have the
> plugins consume a new release of core.

This will only put more stress on proper testing, which is a good thing. You 
can test the new feature/bugfix in core before you put the release out. With 
that you can be reasonably sure that when the plugin gets its hand at the 
functionality, it will work. Obviously this will not work out 100% of the time 
but for me this potential problem does not outweigh the benefits of true 
modular architecture.

> 
> And what is the recourse if the fix in core is deemed bad (which will
> happen)? Release another version of core and go through the same process?
> The need to re-release core will add considerable delays between the time a
> fix is available and the actual testing for the fix to occurs.
> 

Yes and again this is only solvable by competence of developers and processes 
we have in place ;)

The pace of development will slow down overall in RHQ, because to minize the 
problems you outline here, we *really should* start to do code reviews and put 
even more stress on test coverage. If something still slips through our 
testing hands, the process will be more cumbersome and painful than it is 
today. But that is a good thing ;) It will force us to do a better job ;)

> 
> Thank you,
> Stefan Negrea
> 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> 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