commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Mon, 10 Dec 2012 19:47:10 GMT
On 12/10/12 11:40 AM, Phil Steitz wrote:
> On 12/10/12 10:50 AM, Ralph Goers 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.
> Having now looked at [1], it looks to me like we can solve the
> immediate problem using svn pub-sub.  The docs are not clear and
> they may not allow it, but in theory, we could in fact do this
> incrementally - start an svn repo and move the "mutable" portions
> there incrementally, understanding that only changes to the
> svn-migrated stuff will be propagated.  If infra barfs on that, then
> we just commit the whole mess starting at the top level commons
> site, following the Ant example linked on [1].  Then to make
> changes, we follow the process that has been in place for the main
> ASF site for ages - maintain a local checkout of the generated site,
> re-gen when you want to update and check in.
>
> I know playing with the CMS might be fun and interesting; but a) we
> have no volunteers to do this and b) we do not have time to migrate
> all of the content.
>
> Therefore, I suggest we just follow the Ant route; possibly moving
> incrementally if infra allows that.

Let me modify the proposal to make it simpler and more palatable to
infra:

Just do like Ant - check in the whole mess.

Phil
>
> Phil
>
> [1] http://www.apache.org/dev/project-site.html
>> 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?  Any that are not could move to the CMS as
part of the main site.
>>
>> 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
>>
>>


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


Mime
View raw message