GitHub migration again -- The Plan

Stefan Negrea snegrea at redhat.com
Fri Mar 1 14:09:04 UTC 2013



----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, March 1, 2013 5:18:27 AM
> Subject: Re: GitHub migration again -- The Plan
> 
> 
> Am 01.03.2013 um 09:06 schrieb Lukas Krejci:
> 
> > I don't think we need to multiply all the jobs by 3. For example,
> > we have a
> 
> Another example is the compile job, that currently runs for
> Postgres and Oracle, which is redundant
> 
> > plugin. Basically we need to start thinking about the core server
> > as a
> > standalone project.
> 
> We can also go the full mile:
> 
> split out modules/core into a separate repo.
> If we make changes there, we publish a new version of it and
> all the other 3 repos will build agains this published version of
> modules/core/*

The main problem that I see with this model is the time and steps required to get a new build to testing. 
The story for publishing of a fix would go like this:
1) Identify that a fix needs to go into the two repositories (core and plugins)
2) Core repo: commit the fix to github
3) Core repo: increment the version 
3) Core repo: make sure that unit & integration test pass completely
4) Core repo: run through the publish & release process -- this is not a fully automated process
5) Plugins repo: update the core version in the master branch 
6) Plugins repo: publish the fix
7) Build with jenkins a test build.


Will go from 1 commit for such change to at least 4 commits:
1 commit to core with the fix
1 commit to core with the version change
1 commit to plugins with the core version change
1 commit to plugins with the plugins change


Is this an acceptable process to go through at least twice a week (maybe more before a major release due to BZ churn)? And who will be the person that handles this process?



Now to come up with a fix and test locally is a totally different story because I suspect developers will have to have uncommitted changes to point to local version of master branch of core from their master branch of the plugins. (I am just thinking about all the stashing and reapply stashes to make that happen....)


Thank you,
Stefan Negrea

> 
> > While this change will slow down the progress somewhat, I think
> > it's worth it
> > - we will have more fine grained micro releases that will actually
> > track the
> > progress in the core.
> 
> We may/will see some slowdown as well, if we go more to a
> pull-request
> model of contributing. In both cases we would think a little harder
> if a
> change is really needed and if the change is the right one.
> 
> --
> 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
> 
> 
> _______________________________________________
> 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