GitHub migration again -- The Plan

Thomas Segismont tsegismo at redhat.com
Fri Mar 1 13:20:23 UTC 2013


Le 01/03/2013 11:56, Heiko W.Rupp a écrit :
> Stefan,
>
>> The part of the plan that concerns me is the version mismatch between core and the other two repositories when it comes to master branch. I am thinking here for the perspectives of the developer and a Jenkins build.
>>
>>  From a developer perspective, take the scenario where a BZ requires a concurrent fixes in in the plugin repository and the core repositories. I just to not see how one can test such fix easily. Having the HEAD of master branch of both repository on the local disk would not be sufficient. So what would be workflow here?
>
> I know that this is not too easy and totally see your point.
>
> My motivation here is (and otherwise we would not need to discuss about splitting at all):
>
> a user / developer wishing to develop plugins must be able to
>
>    $ git clone github.com/rhq-project/rhq-plugins
>    $ mvn install
>
> without any issues in dependency resolving
>
> We and contributors had issues for years because a potential contributor has to check out a huge pile of sources,
> run a build for a loooong time just to get at a point where the local env is suited to do some plugin development.
>
>
>>
>> Now from the perspective of a Jenkins build. Lets say the developers manages to write the fix. How can we create a Jenkins build with the fix for QA?
>
> How often in reality do we really make changes in modules/core/* for plugin changes?
>
> I had a conversation with Thomas on Irc yesterday who was pointing out the same issue - let me paste that in:
>
> [21:33:59] <tsegismont>	 pilhuhn, you said we would not publish core/* and plugin/* snapshots right?
> [21:34:10] <tsegismont>	 after the split
> [21:34:15] <@pilhuhn>	 yes
> [21:34:55] <@pilhuhn>	 we may at the extreme publish a timed/dated snapshot as in rhq-core-201302282134.jar
> [21:35:07] <tsegismont>	 so what should i do then if, for example, i add some methods to core API and want a plugin to use it?
> [21:35:25] <@pilhuhn>	 But we need to make sure that users can at any time come in, checkout rhq-plugins and build it
> [21:35:35] <@pilhuhn>	 I've described that in the wiki
> [21:35:48] <@pilhuhn>	 we may publish a datd snapshot
> [21:36:03] <@pilhuhn>	 or just a new stable release for modules/core/* as in 4.6.1
> [21:36:10] <tsegismont>	 ok
> [21:36:43] <@pilhuhn>	 publishing -SNAPSHOT or per build -timed snapshots is not going to work with the nexus repos at jboss and even less with central
> [21:37:56] <tsegismont>	 what i fear is that we might be tempted in the future not to change core api just to avoid to build a 4.6.1
> [21:38:11] <@pilhuhn>	 Is that bad?
> [21:38:14] <tsegismont>	 i mean, we will not be willing to do this for minor changes
> [21:39:06] <tsegismont>	 not sure how bad it is, let me give an example
> [21:39:31] <@pilhuhn>	 We need to absolutely make sure that someone who has no ~/.m2/repository can clone rhq-plugins and then run mvn install and succeed
> [21:43:44] <tsegismont>	 yes right
> [21:45:48] <tsegismont>	 back to my example, last time i worked on a plugin, i had to test a whether a String was blank or not. To avoid importing another commons i searched core classes for a StringUtil but there was no method like i wanted. So added it (at the benefit of all plugins) and used it in the plugin. Would you release a 4.6.1 for that?
> [21:46:09] <tsegismont>	 had to test whether (-a)
> [21:49:12] <@pilhuhn>	 It is the question in the sense that we may think a little harder what we will change in the root of the dependency tree.
> [21:49:35] <@pilhuhn>	 And yes, this may sound like a very small change and not warrant a 4.6.1 version of modules/core
> [21:49:57] <@pilhuhn>	 and then we may e.g batch up some of those changes
> [21:50:07] <@pilhuhn>	 or indeed create a timed snapshot
> [21:51:03] <@pilhuhn>	 But : we can not create a timed snapshot every night or on every jenkins run of master, as this will not be accepted by repositories
>
> Hope this makes it more clear
>
>    Heiko
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>

Hi,

That example I took yesterday was obviously not the best one :)

A better one may be the change I made on ProcessInfo API while working 
on some availability checks bugs. With our current process, I deprecated 
some methods and updated some plugins to use the new methods, all in one 
commit.

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).

Note that I'm not saying I prefer the monolithic repository approach. I 
do agree that protecting the core API is a good idea.

Thomas


More information about the rhq-devel mailing list