GitHub migration again -- The Plan

Lukas Krejci lkrejci at redhat.com
Thu Mar 14 13:15:37 UTC 2013


On Tuesday, March 05, 2013 13:17:39 Stefan Negrea wrote:
> ----- Original Message -----
> 
> > From: "Lukas Krejci" <lkrejci at redhat.com>
> > To: rhq-devel at lists.fedorahosted.org
> > Sent: Tuesday, March 5, 2013 10:04:41 AM
> > Subject: Re: GitHub migration again -- The Plan
> > 
> > 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.
> 
> The proposal makes sense for a named release branch (eg. RHQ 4.7.5) where
> entropy is low. Having to go through a more elaborate release process can
> be good measure to increase quality.
> 
> What it does not make sense and I am trying to raise red flags is having
> this situation on master branches. Master branches are unstable by nature
> and the amount of change in these branches is high. If we make our life
> harder just for the sake of having a process I think that will be huge
> mistake.
> 
> If a community developer wants to develop in the master branch then that is
> their choice and they need artifacts from both branches built locally. I
> think it's better to encourage casual community members develop on more
> stable branches anyway. Master branches are expected to be broken from
> time, so why get casual community members frustrated when they could
> develop on more stable branches?
> 
> 
> All what I am advocating is a small departure from the original plan that
> only impacts versioning for master branches. I am just proposing to keep
> all master branches on the same future version and to have them depend on
> the version in master branch. So the master branch of the plugins
> repository will depend on the master branch artifacts of the core
> repository.
>

This makes sense up to the point where you'd like outside contributors to 
provide a fix to an existing plugin. If we had the plugin master depend on the 
core SNAPSHOT version, we'd essentially force the outside contributor to build 
everything from source to be able to test their contribution - as you 
correctly point out. But fixes to the existing plugins is what I think we need 
most from the community and therefore exactly this workflow should be made as 
easy as possible.

I get your point though, if we adopted your approach, life would be easier for 
the core developers (and addmittedly, we write 95%+ of the code).

Maybe it's just my ignorance, but I just don't see that many complications 
with publishing incremental releases more frequently. Don't we have most of 
that automated for RHQ (I've read somewhere in this thread that a release of 
RHQ takes about 8hrs - what takes most of the time in that)?
 
> This has a few advantages for daily development:
> 1) Can write and test a fix locally relatively easy. No stashed changes, no
> uncommitted local changes, etc. 

I disagree here. There is nothing that would force you to write cross-module 
unit tests today and the split of the repos or the indendent versioning of 
core and plugins will not change that.

> 2) Can create test builds easily, almost
> the same process that we have today. 3) Simple process for daily
> development.

Take for example our rhq-probe job to test the ad-hoc changes. If the plugins 
master depended on the unreleased and publicly unavailable core SNAPSHOT 
version, you wouldn't be able to make a rhq-plugins-probe job, because it 
would have nowhere to get the core SNAPSHOT versions from (unless it also 
built core prior to it, which kinda defeats the purpose of split repos ;) ).

> 
> > 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 ;)
> > ).
> 
> I think reality will hit us fast and hard when we will need to release core
> a few times a week just to get builds out for testing purposes.

This is where we differ.. I don't foresee such development.

Where I do see a problem is that we don't have 100% clear demarcation lines 
between server-side and agent-side code. I am specifically talking about 
core/util and core/domain modules that IMHO have out-grown their original 
purpose and especially domain contains many classes that are specific to 
either only server or agent. I.e. we will have trouble figuring out whether 
given change in core/domain affects the agent plugins, because while the 
plugins can access any class from the domain, many of those classes have no 
use or place in plugin code. Of course there will be classes that are needed 
both on server and agent-side but I do think these are much fewer than what we 
currently expose.

But again, being exposed to this problem more than we are now will hopefully 
make us solve it. This will decrease the size of the domain jar and therefore 
of all of our deployments as well as make our code separation better - and 
that is a good thing.




More information about the rhq-devel mailing list