commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: We will not be able to update our websites...
Date Mon, 10 Dec 2012 21:27:20 GMT
Yes, I think you are missing something fundamental.

If you check in "the whole mess" you will never again be able to properly build a sub-project's
site with Maven.  This is because the process of updating the site would require first doing
a diff and then deleting items that are not included in the new version. Someone created a
Maven plugin to try to do this but it is not the way I would want to go at all.

Ralph

On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:

> I don't think there's much percentage in moving to the CMS with a structure
> like that of Commons.  That said, checking in the whole mess, as Phil
> suggests, seems perfectly doable and should not preclude updating parts of
> the tree in quite a similar fashion as how updating a given component's
> site is done today, except no ssh to mino.  Am I missing something
> fundamental?
> 
> Matt
> 
> 
> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> 
>> 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
>> 
>> 


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


Mime
View raw message