I think there are more "problems" with not accepted commits on the code base. The web site is not so many times changed and the docs are usually slightly updated.
And - what would be the problem? A "wrong" website for one day? Jan >-----Ursprüngliche Nachricht----- >Von: Gilles Scokart [mailto:[EMAIL PROTECTED] >Gesendet: Mittwoch, 27. Juni 2007 10:25 >An: [email protected] >Betreff: Re: Web site discussion (was Re: Steps toward graduation) > >Is this techniques often used at apache? I have the impression that >will not work work very well with a commit-then-discuss because the >commit is actually a publish. But that might not be a problem in >practice. What did you advice? > >Gilles > > > >2007/6/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: >> You could also install a cron >> - cd site >> - svn update >> - uploadTo.people.apache.org >> >> Jan >> >> >> >-----Ursprüngliche Nachricht----- >> >Von: Xavier Hanin [mailto:[EMAIL PROTECTED] >> >Gesendet: Dienstag, 26. Juni 2007 17:23 >> >An: [email protected] >> >Betreff: Re: Web site discussion (was Re: Steps toward graduation) >> > >> >On 6/26/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote: >> >> >> >> My preverence would be to store all version depended docs in >> >to to code >> >> base >> >> (manuals, tutorials, articles etc). Where as general docs >> >which never need >> >> to be updated for a release, could go else where (Links to >> >Wiki, Issue >> >> tracking, contribution and so on). >> > >> > >> >I agree, this is what I propose. >> > >> >Xavier >> > >> >Tjeerd >> >> >> >> On 6/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Could we conclude on this subject. I think we really need >> >to improve the >> >> > access to archived versions documentation, and improve >> >google indexing. >> >> > >> >> > Thus I like Jan's suggestion: put the site - i.e. everything but >> >> > documentation and tutorials - in a separate location in svn. My >> >> suggestion >> >> > is: >> >> > https://svn.apache.org/repos/asf/incubator/ivy/site/ >> >> > Documentation would still be in project doc directory. >> >Documentation and >> >> > site would be in two separate xooki, so we would have a >> >TOC for each of >> >> > them, similar to what we got @ jayasoft, see this page for >> >reference: >> >> > http://www.jaya.free.fr/ivy/doc.html >> >> > >> >> > On each release, we would package the documentation of >the released >> >> > version >> >> > (and not the site), and put this packaged doc on the >web site in an >> >> > archived >> >> > documentation section. >> >> > >> >> > Thus the web site would provide access to documentation >of archived >> >> > releases >> >> > (maybe we should limit this to three releases) and version in >> >> development. >> >> > >> >> > We wouldn't use raw xooki pages on web site anymore, but >> >generated ones >> >> > (mainly for google indexing). Updating the web site >would require a >> >> simple >> >> > call to an ant target, which would generate the site and >> >upload it to >> >> > people.apache.org. Same for the documentation of the version in >> >> > development. >> >> > >> >> > If nobody's object I'm ok to take care of that. >> >> > >> >> > What do you think? >> >> > >> >> > Xavier >> >> > >> >> > On 6/19/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: >> >> > > >> >> > > On 6/19/07, Gilles Scokart <[EMAIL PROTECTED]> wrote: >> >> > > > >> >> > > > I like how the menu expands (the sublevel appears >> >progressively). >> >> > > >> >> > > >> >> > > Yes, this is one of the nice effects with jquery. >> >> > > >> >> > > I didn't test the doc generation (I don't have a jdk 1.6 >> >on my machine >> >> > > > :-(). >> >> > > >> >> > > >> >> > > I haven't tested either, I will do. Shouldn't be >> >difficult to fix in >> >> > case >> >> > > of a bug. >> >> > > >> >> > > I notice a problem when I click on "tutorial" (the >page, not the >> >> arrow), >> >> > > > the >> >> > > > menu is not expandable anymore. >> >> > > >> >> > > >> >> > > Good catch, the bug is indeed in all pages which are not >> >at the root >> >> of >> >> > > the doc directory. Will investigate and fix that asap. >> >> > > >> >> > > By the way: >> >> > > > - Do we still need to generate the doc? (I guess yes, for >> >> google. But >> >> > > > there >> >> > > > is maybe other solutions) >> >> > > >> >> > > >> >> > > Which solution are you thinking about? Being badly >> >indexed by google >> >> is >> >> > a >> >> > > huge drawback, so I think it's worth the pain of >> >generating the site. >> >> > When >> >> > > I talk about a pain, it's very slight, since with a good >> >target in our >> >> > ant >> >> > > file it's easy and straightforward (as soon as you have >> >ant 1.7 + java >> >> 6 >> >> > > OR rhino in your ant lib - I haven't tested this last >> >option but we >> >> > should >> >> > > be able to make it work). >> >> > > >> >> > > - Do you really want to publish the new site. I'm not >> >sure, but it >> >> can >> >> > > > contain doc of things that will only be released in >> >2.0-alpha-2. >> >> > > >> >> > > >> >> > > This is something that can be discussed indeed. IMO I'd >> >like to have >> >> the >> >> > > history of old documentations (at least two last >> >releases) and the >> >> > current >> >> > > in development one on the site. With the file based >> >approach we have >> >> > it's >> >> > > not too difficult, but for the moment we only have the >> >latest one. The >> >> > main >> >> > > thing to do to get several labelled versions available >> >on site is to >> >> > > separate the documentation from the site itself: we >> >don't need to put >> >> an >> >> > > history of the whole site was at one release, but only the >> >> documentation >> >> > > and tutorials sections). I should be able to do some >> >javascript to be >> >> > able >> >> > > to extract a part of a xooki site automatically if >you think it's >> >> worth >> >> > > it. For the last release ( 1.4.1), I think it would >be useful to >> >> provide >> >> > > the doc online too, but I'm not sure we'll manage to >separate the >> >> > sitefrom the doc. >> >> > > >> >> > > WDYT? >> >> > > >> >> > > Xavier >> >> > > >> >> > > Gilles >> >> > > > >> >> > > > >> >> > > > > -----Original Message----- >> >> > > > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] >> >> > > > > Sent: mardi 19 juin 2007 9:39 >> >> > > > > To: [email protected] >> >> > > > > Subject: Re: Steps toward graduation >> >> > > > > >> >> > > > > On 6/12/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> >> > > > > > >> >> > > > > > On Mon, 11 Jun 2007, Xavier Hanin < >[EMAIL PROTECTED]> >> >> wrote: >> >> > > > > > > On 6/11/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote: >> >> > > > > > >> >> >> > > > > > >> On Thu, 7 Jun 2007, Xavier Hanin >> ><[EMAIL PROTECTED]> >> >> > wrote: >> >> > > > > > >> >> >> > > > > > >> > - The code base must contain only ASL or >> >> ASL-compatible >> >> > > > > > >> > dependencies >> >> > > > > > >> >> >> > > > > > >> In the case of the non-ASLed JavaScript stuff >> >I'd like to see >> >> a >> >> > > > > > >> solution other than "we don't ship it" since >> >legally having >> >> > > > > > >> something in svn means distributing it. >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > I can replace the dependency on ddtree by >another js tree >> >> > > > > > > component. We can use jquery [1] and the tree >> >view plugin [2] >> >> > for >> >> > > > > > > instance. Both are released under a dual GPL and >> >MIT license >> >> > [3], >> >> > > > > > > and MIT license seems to be compatible with ASL >> >[4]. So, may I >> >> > go >> >> > > > > > > this way? >> >> > > > > > >> >> > > > > > Yes, the MIT license is compatible with the AL, so >> >which one you >> >> > > > > > choose is a purely technical decision and that I >> >leave up to >> >> those >> >> > > > > > who'll have to work with whatever is chosen 8-) >> >> > > > > >> >> > > > > >> >> > > > > I've just checked in an upgraded version of xooki >> >which does not >> >> > rely >> >> > > > any >> >> > > > > more on ddtree: I've actually removed the dependency >> >on a tree >> >> > > > component, >> >> > > > > recent tree components are usually able to deal with >> >simple ul / >> >> li. >> >> > > > So in >> >> > > > > our case I've set up a jquery tree (MIT licensed) to >> >manage our >> >> tree >> >> > > > menu. >> >> > > > > The modification is in svn, could someone try it >> >before I upgrade >> >> > the >> >> > > > web >> >> > > > > site? >> >> > > > > >> >> > > > > Xavier >> >> > > > > >> >> > > > > Stefan >> >> > > > > > >> >> > > > > > > [1] http://jquery.com/ >> >> > > > > > > [2] >> >> http://bassistance.de/jquery-plugins/jquery-plugin-treeview/ >> >> > > > > > > [3] http://docs.jquery.com/License >> >> > > > > > > [4] http://wiki.apache.org/jakarta/LicenceIssues >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > -- >> >> > > > > Xavier Hanin - Independent Java Consultant >> >> > > > > Manage your dependencies with Ivy! >> >> > > > > http://incubator.apache.org/ivy/ >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > -- >> >> > > Xavier Hanin - Independent Java Consultant >> >> > > Manage your dependencies with Ivy! >> >> > > http://incubator.apache.org/ivy/ >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Xavier Hanin - Independent Java Consultant >> >> > Manage your dependencies with Ivy! >> >> > http://incubator.apache.org/ivy/ >> >> > >> >> >> > >> > >> > >> >-- >> >Xavier Hanin - Independent Java Consultant >> >Manage your dependencies with Ivy! >> >http://incubator.apache.org/ivy/ >> > >> > > >-- >Gilles SCOKART >
