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