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. Cheers, Brett > On 26 Jan 2015, at 9:41 am, Brent Atkinson <brent.atkin...@gmail.com> 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 <brent.atkin...@gmail.com> > 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 <dr.louis.sm...@gmail.com> >> 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 <br...@apache.org> wrote: >>> >>>> >>>> On 20 May 2014, at 1:17 am, Brent Atkinson <brent.atkin...@gmail.com> >>>> 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 >>>> >>>> >>> >> >>
