karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie G." <jamie.goody...@gmail.com>
Subject Re: Karaf first birthday concall minute notes
Date Fri, 17 Jun 2011 12:39:43 GMT
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).

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.

Cheers,
Jamie

On Fri, Jun 17, 2011 at 9:12 AM, Guillaume Nodet <gnodet@gmail.com> 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 <james@fusesource.com> 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 <james@fusesource.com> wrote:
>>> On 17 June 2011 12:16, Christian Schneider <chris@die-schneider.net> 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: james@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: jstrachan, fusenews
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration and Messaging
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> 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
>

Mime
View raw message