On Fri, Jun 17, 2011 at 14:39, Jamie G. <[email protected]> wrote: > Good morning all, > > It was really nice getting to put voices to the names here on IRC > yesterday. I think having these community conference calls are a great > way to bring our global team together :) > > Jean-Baptiste, the meeting notes look good. I really like the idea of > having these calls regularly every 2 or 3 months. > > As to scalate... > > As a mechanism to produce the manuals I'm fine with its usage. > > As a mechanism to produce our website I've had several issues, and > quite frankly just do my best to get past them with copious amounts of > help over IRC from community members. To be honest, updating a wiki or > scalate site requires the contributor to learn some amount of a > framework - wikis being common lowers the bar in general while scalate > requires something of an investment of time (not that its huge). I > think what slows or stops a new user from jumping into altering the > website (contributing a patch) is that hitting scalate for the first > time it may appear to be more daunting than it is... it definitely is > more work to do, requiring more touch time to get things all together > (just my experience). Perhaps the solution is to create a tutorial on > how to update the site, that explicitly shows a user where to get the > code, how to build/test it, and where to create the JIRA & attach > their patch. Another tutorial should also be made to explain how the > karaf site it put together; I know that during each release I spend > far too much time trying to find all the places I need to update or > append to in the source, vs the old just add page where I want it on > the wiki site (perhaps there is a better way I am unfamiliar with, if > there is please let me know).
Yeah, you're right. We should have a web page that can be used as a tutorial for updating the web site. > > Setting up a nightly CI build to deploy the website nightly would help > keep the site more up to date with recent commits. I have to agree > with Christian that updates to the website have been slow getting into > production. I know from my experience setting up to update our webpage > took a bit of messing around, so not having to do that would be a > boost to productivity. This being said do we have a username/password > combo that we can leave on the CI box? The current setup requires > committer credentials to upload/deploy the site, perhaps infra has an > account such as this already created though - we should find out from > them if something like that is available. Good point. As a work around, a small cron job would do the trick, but CI would be way better if possible. > > Cheers, > Jamie > > On Fri, Jun 17, 2011 at 9:12 AM, Guillaume Nodet <[email protected]> wrote: >> The setup is slightly different as we have two web sites, one for the >> manuals which is versioned and one for the main web site which isn't. >> Things such as committers list, board reports and such aren't really >> tied to a release schedule imho. >> >> On Fri, Jun 17, 2011 at 13:38, James Strachan <[email protected]> wrote: >>> BTW we found on the Scalate project we wanted 2 continuous website >>> builds; the current production site branch (i.e. docs for the last >>> major release); so the thing to make http://karaf.apache.org/. Then a >>> continuous build of the new version (trunk); >>> http://karaf.apache.org/versions/3.0-SNAPSHOT (or whatever). >>> >>> Then folks can update the current production website in one branch; or >>> update what will be the next major release (which may be months away); >>> but folks can still view/read the docs for trunk on the website if >>> they want. >>> >>> Also when a release is made, the docs are deployed to a fixed area: >>> http://karaf.apache.org/versions/2.2.3/ or whatever. Then you've just >>> gotta maintain the http://karaf.apache.org/versions/index.html page to >>> link to the various available versions etc. >>> >>> >>> On 17 June 2011 12:28, James Strachan <[email protected]> wrote: >>>> On 17 June 2011 12:16, Christian Schneider <[email protected]> wrote: >>>>> Am 17.06.2011 12:53, schrieb Guillaume Nodet: >>>>>> >>>>>> Over the last 5 years, I've rarely seen people contributing a lot to >>>>>> the doc without being or becoming committers. >>>>>> I don't want to change a technical decision based on the fact that >>>>>> people *might* need something, but rather what people actually need. >>>>>> You are a committer, so you can access / modify the documentation >>>>>> without any problems. So what are your real problems with the current >>>>>> solution ? We can easily set up nightly uploads or even an hourly >>>>>> cron job (though given the change rate, i think a nightly one should >>>>>> be sufficient). If you need an editor, you always find some software >>>>>> I think such as >>>>>> http://www.labnol.org/software/wysiwyg-wiki-editor/18062/ though I >>>>>> tend to use the "mvn jetty:run" which works quite well as you can see >>>>>> your changes immediately. >>>>> >>>>> For me as a committer now it is ok. I also do not have problems with >>>>> editing >>>>> wiki syntax text files by hand. After reading all the comments I think >>>>> that >>>>> the solution is good for now. I just fear that we might not really attract >>>>> people to help. But you are right people who just work on the >>>>> documentation >>>>> are rare anyway. >>>>> >>>>> It would be great if we could establish an automatic update of the website >>>>> for trunk and the current production branch. Ideal would be a script like >>>>> in >>>>> jenkins that only fires when there are real changes then it can be run in >>>>> very short cycles. >>>> >>>> Its really no different from a regular continuous integration build >>>> really; building & deploying the website is just a different mvn >>>> plugin so its like doing snapshot deploy builds. >>>> >>>> >>>>> Btw. How about using jenkins to update the website? The >>>>> update just has to be callable from maven and we have to authenticate in >>>>> some way. Jenkins would also allow to track when and why updates have beem >>>>> done. >>>> >>>> We've been doing this on the Scalate project for a while btw; its just >>>> a matter of setting up a jenkins build in the right branch and using a >>>> profile in the maven build to do the deploy of the website project (as >>>> you probably don't want other builds deploying the website by >>>> default). >>>> >>>> This kinda thing does the trick in the website pom... >>>> >>>> <plugin> >>>> <groupId>org.fusesource.scalate</groupId> >>>> <artifactId>maven-scalate-plugin</artifactId> >>>> <version>${project.version}</version> >>>> <configuration> >>>> >>>> <remoteServerId>people.apache.org</remoteServerId> >>>> >>>> <!-- server stuff here - scp or dav or whatnot... --> >>>> <!-- TODO fixme - i just made this up .... ---> >>>> >>>> <remoteServerUrl>scp:people.apache.org:/www/karaf.apache.org/versions/${project.version}</remoteServerUrl> >>>> </configuration> >>>> <executions> >>>> <execution> >>>> <id>sitegen</id> >>>> <goals> >>>> <goal>sitegen</goal> >>>> </goals> >>>> <phase>package</phase> >>>> </execution> >>>> <execution> >>>> <id>deploy</id> >>>> <goals> >>>> <goal>deploy</goal> >>>> </goals> >>>> <phase>deploy</phase> >>>> </execution> >>>> </executions> >>>> </plugin> >>>> >>>> -- >>>> James >>>> ------- >>>> FuseSource >>>> Email: [email protected] >>>> Web: http://fusesource.com >>>> Twitter: jstrachan, fusenews >>>> Blog: http://macstrac.blogspot.com/ >>>> >>>> Open Source Integration and Messaging >>>> >>> >>> >>> >>> -- >>> James >>> ------- >>> FuseSource >>> Email: [email protected] >>> Web: http://fusesource.com >>> Twitter: jstrachan, fusenews >>> Blog: http://macstrac.blogspot.com/ >>> >>> Open Source Integration and Messaging >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
