commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Mon, 10 Dec 2012 19:34:30 GMT
On Mon, Dec 10, 2012 at 7:50 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> All the sub-sites are hooked off the main site.  I would have no idea how to migrate
anything without migrating the main site first.
>
> I suppose it is possible to point to the sub-sites in their current location but in logging
we found it more beneficial to simply copy the content under the main site in the CMS.
>
> Are all the sub-sites built with Maven?

Yes, but to my knowledge different versions of maven (2 vs 3).

> Any that are not could move to the CMS as part of the main site.

Actually I think it would be good for Commons too. Some projects may
keep some old version websites. Therefore it might be nice to maintain
the mainsite with the CMS and copy/paste the components to the svn
part.

Just my 2 cents.

>
> Ralph
>
>
> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>
>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>> That is what we did in logging. Changing it at the end is fairly easy.  However,
we don't have much time for testing.
>>
>> Do we really have to do it all at once?
>>
>> IIUC (which is quite possibly false), the intent here is to get
>> everyone onto svn pub-sub and kill off the rsync processes from
>> p.a.o to the live site.  The stake in the ground is that the rsyncs
>> are going to stop Jan 1.  Do I have that right?
>>
>> Why can't we move to svn pub-sub incrementally somehow,
>> understanding that until individual components move, their sites
>> will be read-only?  So basically, when you decide to make changes to
>> a site, you get it set up for svn pub-sub?  Note I am including the
>> main site in this - i.e., it does not have to "move" until it needs
>> to be changed.  It would seem to me (again, may be missing something
>> critical) that we could build the newly definitive source svn repo
>> incrementally, with publishing always sourced from there, but "old"
>> directories on the live host remaining until they get clobbered.  In
>> the worst case, if the live host *must* include only svn-published
>> files, we could seed the new repo with the "old" content.  But I
>> don't get why that has to be the case; because if it is, we are in
>> worse shape than Christian suggests - come Jan 1 we will be dark if
>> we don't get everything moved to svn pub-sub.
>>
>> Sorry if above is naive.  The intent is to avoid a huge amount of
>> fiddling in a short period of time when quite a few component sites
>> have not changed and will not change for some time to come.
>>
>> Phil
>>
>>
>>>
>>> Ralph
>>>
>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>
>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>> we have many components, unless you see a short cut.
>>>> I thought we would create: commons-test.apache.org
>>>> move all components to there and then make a switch from
>>>> commons.apache.org to the new site
>>>>
>>>>
>>>>
>>>>
>>>>> Gary
>>>>>
>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <grobmeier@gmail.com>
wrote:
>>>>>
>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>> Bah, let's pick one component and start there and skip a test
site.
>>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <grobmeier@gmail.com>
wrote:
>>>>>>>
>>>>>>>> starting from 1. January. Just saw a final reminder from
Infra.
>>>>>>>>
>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>
>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>
>>>>>>>> In other terms: let us request a commons-test cms where we
can try things
>>>>>>>> out and prepare the new sites.
>>>>>>>>
>>>>>>>> As Ralph Goers has already mentioned, we have a similar structure
in
>>>>>>>> logging land (1 main site, several sub sites) which might
fit to Commons
>>>>>>>> too.
>>>>>>>>
>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
are
>>>>>>>> generated via Maven. The target of this generation is then
copied to
>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>
>>>>>>>> Obviously we will have to generate sites for each component
then, which
>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.grobmeier.de
>>>>>>>> https://www.timeandbill.de
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.grobmeier.de
>>>>>> https://www.timeandbill.de
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message