----- Original Message -----
From: "Lukas Krejci" <lkrejci(a)redhat.com>
To: rhq-devel(a)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 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.
2) Can create test builds easily, almost the same process that we have today.
3) Simple process for daily development.
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.
See inline for more concrete comments...
On Monday, March 04, 2013 11:30:39 Stefan Negrea wrote:
> ----- Original Message -----
>
> > From: "Heiko W.Rupp" <hrupp(a)redhat.com>
> > To: rhq-devel(a)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 good process is one that is completely automated (with no manual steps). And we will
be far from good with a complicated manual release process for testing small changes on
master branches.
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 ;)
There should always be some gain for a loss. Slower development, complicated daily
development process, complicated build procedures for test builds are all major losses for
me. What are a comparable gains that outweigh these problems?
>
> Thank you,
> Stefan Negrea
>
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel