karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Karaf first birthday concall minute notes
Date Fri, 17 Jun 2011 14:05:03 GMT
Perhaps the account where jenkins runs has a ssh key. Then we could 
allow this key on the server. I think infra could do such a thing in 
their settings.xml.

Christian

Am 17.06.2011 15:23, schrieb Guillaume Nodet:
> On Fri, Jun 17, 2011 at 14:39, Jamie G.<jamie.goodyear@gmail.com>  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<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
>>>
>
>


-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message