continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Using git for a possible 1.4.3 release
Date Mon, 26 Jan 2015 10:32:44 GMT
Hi Brent,

Migrating to git and getting a timely release out to make sure everything works sounds good.
Probably the only hesitation would be if it absorbs time that prevents getting the release
out, since it sounds important - but if you can manage, go for it.

Let me know how I can help... I don't have a lot of time to work on it right now, but happy
to answer questions / test / review, etc.


> On 26 Jan 2015, at 9:41 am, Brent Atkinson <> wrote:
> Greetings,
> I would like to re-open this discussion in the context of a 1.4.3 bugfix
> release.
> The git mirror grants many of the same benefits of git, but having both
> subversion and git involved in the development and release processes adds
> complexity. I would like to simplify and gain the ability to directly use
> branches for contribution and review, perhaps even through social coding
> sites to make contribution simpler for the contributor.
> I'm wondering: I recently updated continuum to the latest version of
> struts2 while working on CONTINUUM-2723. Since a major part of the
> migration is updating the release process and we have a reason  to release,
> security and blocker defects, Do you think it would make sense to attempt a
> quick 1.4.3 release with git?
> Brent
> I'm willing to do the necessary leg work, and a good chunk of time to do
> it. I'm wondering
> On Tue, May 20, 2014 at 10:40 AM, Brent Atkinson <>
> wrote:
>> Louis,
>> Thank you for offering your feedback. My understanding so far was that we
>> were talking about the relevance and logistics of the different ideas. It
>> did not make sense to talk about schedule quite yet because it wasn't clear
>> we would want to do it. Also, I didn't think we were talking about making
>> major changes to the implementations necessarily.
>> The git migration is a source control-only change, it does not include
>> changing continuum's support for git. The talk about svnpubsub, the parent
>> pom and Apache CMS was in response to my query about what effects migrating
>> to read/write git would have on how we manage the rest of the project. It
>> should not affect functionality.
>> The source code reorganization would be about moving the code around to
>> redraw the module boundaries. While there might be functionality impacts
>> due to the scope of what would be changing, it would mostly be moving code
>> and not rewriting it (for now).
>> I think it makes sense to talk about release timing, but it probably makes
>> sense as a separate thread still.
>> Brent
>> On Tue, May 20, 2014 at 7:09 AM, Louis Smith <>
>> wrote:
>>> Should all the initiatives under discussion be combined into a major
>>> project?  Make this Continuum 3.0?  Include full GIT support, move to GIT,
>>> re-factor (per the other thread), move reports to Apache CMS... Seems like
>>> a HUGE amount of work has been discussed when you collapse the various
>>> threads here.
>>> How large is the Continuum user base at this point?  How would this impact
>>> them?  What would the upgrade path be?
>>> From my point of view, I have nearly 300 projects (200 or so "active) in
>>> one of my clients SDI.  With nearly 2 dozen support libraries, 10
>>> multi-module,  80 "under development" up to the 64 in production.
>>> Releases
>>> are done almost daily.
>>> A major "upgrade" impact would be something we would have to carefully
>>> schedule - but it would actually be easier than 4 or 5 smaller ones.
>>> Just random thoughts from the old man who hasn't had enough coffee yet...
>>> Louis
>>> Dr. Louis Smith, ThD
>>> Chief Technology Officer, Kyra InfoTech
>>> Museum Director, Veterans Memorial Railroad
>>> On Mon, May 19, 2014 at 9:37 PM, Brett Porter <> wrote:
>>>> On 20 May 2014, at 1:17 am, Brent Atkinson <>
>>>> wrote:
>>>>> That is encouraging. I am happy to do this myself if people find it
>>>>> valuable. The project is already converted to git as you said.
>>> However,
>>>> how
>>>>> site publishing and the parent pom fit into this is not clear to me.
>>> Not
>>>>> knowing the ins and outs of the Apache-specific processes like svn
>>> pubsub
>>>>> and how and when parent poms are staged (just for example), it is not
>>>> clear
>>>>> what effect if any moving to git would have.
>>>> Really no effect there - svnpubsub is still used for the site publish,
>>> but
>>>> it's a checkout from a separate SVN repo. Likewise, the parent POM is
>>>> published to an artifact repository, so that's the same.
>>>> Whether the site & parent POM get moved to Git or left in SVN is
>>> something
>>>> to decide. I'd suggest just starting with the main trunk and approach
>>> the
>>>> others later if needed. For example, we might later decide to use the
>>>> Apache CMS for the site instead of a Maven project, and in that case the
>>>> parent POM probably isn't needed.
>>>>> I am more than happy to figure
>>>>> it out, though I may need help identifying the most relevant channels
>>> to
>>>> do
>>>>> it.
>>>> I think the steps are:
>>>> - hold a vote here
>>>> - if passed, ask infra to convert the repository and coordinate with the
>>>> list
>>>> - once done, go through the POMs, developer and contributor
>>> documentation
>>>> and make sure repository references point to the new location
>>>> As always, I'm happy to help - I just don't have cycles to drive that at
>>>> the moment.
>>>> Cheers,
>>>> Brett

View raw message