commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Mon, 10 Dec 2012 21:49:50 GMT
Ralph,
  Thanks for your response, and sorry if I'm still being dense, but let's
just use the [lang] component as an example.  Why can't I, at any point,
generate the component's site locally, then surgically modify svn so that
lang/ from the content root now contains the generated content?  Where does
a diff become necessary?

Matt


On Mon, Dec 10, 2012 at 3:27 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> 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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message