GitHub migration again -- The Plan

Stefan Negrea snegrea at redhat.com
Fri Mar 1 13:46:15 UTC 2013


Hello,


Thomas, both of your examples from below are perfect. One of them is trivial (StringUtil change) while the other might be a little more involved. In both cases the immediate reaction would be ... "ohhh, I need to change and republish core? Let me see if I can accomplish this in another way." And avoid as much as possible changing core. With the StringUtil change, one would most likely write that functionality straight into the plugin and avoid changing core altogether.

Another implications of this type of versioning is that we will in fact no longer have a true core master branch (with a SNAPSHOT version) because we will be forced to officially publish every 2-3 changes.


Thank you,
Stefan Negrea


----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, March 1, 2013 7:20:23 AM
> Subject: Re: GitHub migration again -- The Plan
> 
> 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
> _______________________________________________
> 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