Simon Kaegi | 24 Jul 19:33 2014
Picon

[orion-dev] Orion Dev Meetings now Tuesday at 10AM EST

Starting July 28th we've moved the Orion weekly Dev meetings to Tuesday at 10AM EST.

Dial-in Information:
---------------------------

    North America 1-866-569-4992
    Germany 49-692-2224-6059
    France 33-(0)-17-070-8535
    UK 0800-033-7806
    Switzerland 41-44-580-2115
    Sweden 46-85-063-8386
    Italy 003-902-3604-8268

    Participant conference extension: 703, then enter pin 14554

    * SIP clients can call 703-DkbrB8mJDsZjP7fbyOvOZWD2FQJk+8+b@public.gmane.org, then enter pin 14554.
-----

https://wiki.eclipse.org/Orion/Meeting_minutes
<div>
<p>Starting July 28th we've moved the Orion weekly Dev meetings to Tuesday at 10AM EST.<br><br>Dial-in Information:<br>---------------------------
</p>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="548">
<ul>North America 1-866-569-4992<br>Germany 49-692-2224-6059<br>France 33-(0)-17-070-8535<br>UK 0800-033-7806<br>Switzerland 41-44-580-2115<br>Sweden 46-85-063-8386<br>Italy 003-902-3604-8268<br><br>
Participant conference extension: 703, then enter pin 14554<br><br>
* SIP clients can call <a href="mailto:703@...">703@...</a>, then enter pin 14554.</ul>
</td></tr></table>-----<br><br><a href="https://wiki.eclipse.org/Orion/Meeting_minutes">https://wiki.eclipse.org/Orion/Meeting_minutes</a>
</div>
Mark Macdonald | 24 Jul 19:01 2014
Picon

[orion-dev] Meeting minutes for July 24th

Note that the Orion development call has been moved to Tuesdays at 10:00 AM EST. Next week's call is on Tuesday, July 29th.

Mark
<div><div dir="ltr">
<div class="gmail_default">
<a href="https://wiki.eclipse.org/Orion/Meeting_minutes/20140724">https://wiki.eclipse.org/Orion/Meeting_minutes/20140724</a><br><br>
</div>
<div class="gmail_default">Note that the Orion development call has been moved to Tuesdays at 10:00 AM EST. Next week's call is on Tuesday, July 29th.<br><br>
</div>

<div class="gmail_default">Mark<br>
</div>
</div></div>
John Arthorne | 23 Jul 17:30 2014
Picon

Re: [orion-dev] Orion Scalability

Hi Michael,

To add to what Paul said, essentially we have not yet hit a memory or CPU choke point in real world usage yet. Our Solr index has hit a limit but that is based on workspace size, and Solr supports sharding of indexes - we just need to use it. The real world usage tends to be 99% basic file operations and Git operations are much less frequent. There is still at least a security issue of ensuring that we throttle Git operations to avoid the server crashing. We are actively making Orion support clustering - there are several use cases motivation this: instant fail over, zero downtime deployment of new builds, and eventually multiple active instances to support load.

John





From:        Paul Webster <pwebster-cmaem7PIVQT44Nm34jS7GywD8/FfD2ys@public.gmane.org>
To:        Orion developer discussions <orion-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>,
Date:        07/23/2014 10:45 AM
Subject:        Re: [orion-dev] Orion Scalability
Sent by:        orion-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org



Hi Michael,


On Tue, Jul 22, 2014 at 7:47 AM, Ochmann, Michael <michael.ochmann-y6kNeMnOB+c@public.gmane.org> wrote:
Therefore my question: Do you have any experience how many cores and how much memory one should spend for an Orion instance with 1000 truly concurrent users? Or is that attempt futile and we should turn to cluster operation directly?

You might still be able to get away with throwing more memory and cores at Orion to scale up the number of concurrent users, I'm not sure what the choke points would be.

But the work we're doing now is looking at the cluster approach.  Put something in front of the Orion instances (like http://nginx.org/), split out the content and search indices so they can be shared, and run multiple servers against a common content and common search directory.

PW

--
Paul Webster
Hi floor.  Make me a sammich! - GIR _______________________________________________
orion-dev mailing list
orion-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
<div>Hi Michael,
<br><br>To add to what Paul said, essentially
we have not yet hit a memory or CPU choke point in real world usage yet.
Our Solr index has hit a limit but that is based on workspace size, and
Solr supports sharding of indexes - we just need to use it. The real world
usage tends to be 99% basic file operations and Git operations are much
less frequent. There is still at least a security issue of ensuring that
we throttle Git operations to avoid the server crashing. We are actively
making Orion support clustering - there are several use cases motivation
this: instant fail over, zero downtime deployment of new builds, and eventually
multiple active instances to support load.
<br><br>John
<br><br><br><br><br><br>From: &nbsp; &nbsp; &nbsp;
&nbsp;Paul Webster &lt;pwebster@...&gt;
<br>To: &nbsp; &nbsp; &nbsp;
&nbsp;Orion developer discussions
&lt;orion-dev@...&gt;, 
<br>Date: &nbsp; &nbsp; &nbsp;
&nbsp;07/23/2014 10:45 AM
<br>Subject: &nbsp; &nbsp;
&nbsp; &nbsp;Re: [orion-dev]
Orion Scalability
<br>Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;orion-dev-bounces@...
<br><br><br><br>Hi Michael,
<br><br>
<br>On Tue, Jul 22, 2014 at 7:47 AM, Ochmann, Michael &lt;<a href="mailto:michael.ochmann@..." target="_blank">michael.ochmann@...</a>&gt;
wrote:
<br>Therefore my question: Do you have any experience how
many cores and how much memory one should spend for an Orion instance with
1000 truly concurrent users? Or is that attempt futile and we should turn
to cluster operation directly?
<br><br>You might still be able to get away with throwing more
memory and cores at Orion to scale up the number of concurrent users, I'm
not sure what the choke points would be.<br>
<br>But the work we're doing now is looking at the cluster
approach.&nbsp; Put something in front of the Orion instances (like <a href="http://nginx.org/">http://nginx.org/</a>),
split out the content and search indices so they can be shared, and run
multiple servers against a common content and common search directory.<br>
<br>PW
<br><br>
-- <br>
Paul Webster<br>
Hi floor.&nbsp; Make me a sammich! - GIR _______________________________________________<br>
orion-dev mailing list<br>
orion-dev@...<br>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit<br><a href="https://dev.eclipse.org/mailman/listinfo/orion-dev">https://dev.eclipse.org/mailman/listinfo/orion-dev</a>
<br>
</div>
Kris De Volder | 22 Jul 19:28 2014

[orion-dev] Plugins that requires authentication?

I'm trying to integrate some flux authentication support into the flux-orion plugin that Alex made.

I know you can add a 'login' url to a plugin and I know how to add this url. However I can't find much if any documentation about this 'login' link, how it is used and how it interacts with plugin lifecycle.

Also, clicking the github plugin 'login' link doesn't seem to work (I only get a 404).

So I have a few questions

1) I need a way to ensure a user is logged in (via the flux-plugin login url) before the plugin is loaded.
Is this possible? (Basically, the plugin isn't really valid and won't work unless a user is authenticated before the plugin is loaded).

2) what happens when you use the login link again and login as a different user? Does the plugin get reloaded?

3) Is there documentation or examples of the proper/recommended way to create a plugin that requires some kind of authentication before its functionality can be used?

Kris
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div><div>
<div>I'm trying to integrate some flux authentication support into the flux-orion plugin that Alex made.<br><br>
</div>I know you can add a 'login' url to a plugin and I know how to add this url. However
 I can't find much if any documentation about this 'login' link, how it 
is used and how it interacts with plugin lifecycle.<br>
</div></div>
<br>
</div>
<div>Also, clicking the github plugin 'login' link doesn't 
seem to work (I only get a 404).<br><br>
</div>
<div>So I have a few questions<br>
</div>
<div><br></div>1) I need a way to ensure a user is logged in (via the flux-plugin login url) before the plugin is loaded.<br>
</div>Is
 this possible? (Basically, the plugin isn't really valid and won't work
 unless a user is authenticated before the plugin is loaded).<br><br>
</div>2) what happens when you use the login link again and login as a different user? Does the plugin get reloaded?<br><br>
</div>3)
 Is there documentation or examples of the proper/recommended way to create a plugin
 that requires some kind of authentication before its functionality can 
be used?<br><br>
</div>Kris<br>
</div></div>
John Arthorne | 21 Jul 19:44 2014
Picon

Re: [orion-dev] orion.eclipse.org outage

Denis restarted the vserver, I restarted Orion, and we are back in business!

John




From:        John Arthorne/Ottawa/IBM
To:        orion-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org,
Date:        07/21/2014 11:09 AM
Subject:        orion.eclipse.org outage


To save anyone else pinging me... orion.eclipse.org is down and I don't know why or how to fix it. Entered this bug for webmaster to help us:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026

I suspect it is related to the wider eclipse.org outage last night.

orionhub.org is fine though ;)

John

<div>Denis restarted the vserver, I restarted
Orion, and we are back in business!
<br><br>John
<br><br><br><br><br>From: &nbsp; &nbsp; &nbsp;
&nbsp;John Arthorne/Ottawa/IBM
<br>To: &nbsp; &nbsp; &nbsp;
&nbsp;orion-dev@...,

<br>Date: &nbsp; &nbsp; &nbsp;
&nbsp;07/21/2014 11:09 AM
<br>Subject: &nbsp; &nbsp;
&nbsp; &nbsp;orion.eclipse.org
outage
<br><br><br>To save anyone else pinging me... orion.eclipse.org
is down and I don't know why or how to fix it. Entered this bug for webmaster
to help us:
<br><br><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026">https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026</a>
<br><br>I suspect it is related to the wider
eclipse.org outage last night.
<br><br>orionhub.org is fine though ;)
<br><br>John
<br><br>
</div>
John Arthorne | 21 Jul 19:03 2014
Picon

Re: [orion-dev] Process for converging on stable/release builds

Hi Matthias,

I am happy to start using Gerrit more, but there are some issues with using it for this situation:

1) The Gerrit workflows appear to be broken in the current Orion builds (bug 439345) so for everyone self-hosting this is a blocker.

2) I'm not convinced it solves the same problem, but it could be that I don't fully understand the powers of Gerrit. As far as I can tell, Gerrit adds processes and checks *before* integration with the main stream. Code review and automated tests catch some problems, but many more slip through these initial checks and it is only after the change is integrated and pushed on orion.eclipse.org and we start self-hosting that we find the problem. Eventually we might have enough tests that this becomes a rare event, but currently it is quite common. So far we have no performance tests, and no page-level integration tests for the UI. Essentially this appears to me the same as Anthony's "never introduce bugs in master" proposal, which is great in theory, but until we are consistently doing that it is not sufficient.

Having said that, if we can get the Gerrit workflows working in Orion, together with automated build & test for uploaded patches, I'm sure it would help us to reduce the number of bugs introduced and might get us to the point where we no longer need a stable branch.

John




From:        Matthias Sohn <matthias.sohn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To:        Orion developer discussions <orion-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>,
Date:        07/18/2014 04:11 AM
Subject:        Re: [orion-dev] Process for converging on stable/release builds
Sent by:        orion-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org



On Thu, Jul 17, 2014 at 7:43 PM, John Arthorne <John_Arthorne-G1DYhSM1WHTQT0dZR+AlfA@public.gmane.org> wrote:
During Orion 7.0 we have completely stopped doing milestones in favour of a more continuous delivery model. We would like to produce regular (roughly weekly) stable builds that can be deployed to orionhub.org. One issue with this is how to stabilize the code for a stable build without disrupting ongoing development in master. After discussing ideas with various committers I would like to propose a process of branching once per week at a predictable time, and use that to converge on a stable build while allowing master branch to continue development.

https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process

I have done a test drive of this process this week. I setup new "stable" build in Hudson that builds from a branch:

https://hudson.eclipse.org/orion/job/orion-client-stable/

I used this to produced a stable 7.0 S1 (Orion 7 stable build #1) that I have deployed to orionhub.org:

http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html

Committers please take a look at this proposed process and respond here with any thoughts and concerns. 

this sounds like a manual implementation of a process pretty similar to the one supported by Gerrit.
So why don't we adopt the Gerrit code review workflow instead to reach an always stable master branch ?

- Instead of pushing to master everybody would push (all changes) to refs/for/master
- Gerrit creates a new change / patchset for reviewing
- new change / patchset triggers Hudson to run a build / tests
- Hudson votes +1 if build / tests succeed or -1 if build /tests fail
- other committers / integrator of the week review changes pending in review and vote
- changes in review which got approved in review are submitted
- Hudson builds / tests resulting new version on master branch
- if some submitted change turns out to be bad revert it (to my experience this happens very rarely)

--
Matthias _______________________________________________
orion-dev mailing list
orion-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
<div>Hi Matthias,
<br><br>I am happy to start using Gerrit more,
but there are some issues with using it for this situation:
<br><br>1) The Gerrit workflows appear to be
broken in the current Orion builds (bug 439345) so for everyone self-hosting
this is a blocker.
<br><br>2) I'm not convinced it solves the same
problem, but it could be that I don't fully understand the powers of Gerrit.
As far as I can tell, Gerrit adds processes and checks *before* integration
with the main stream. Code review and automated tests catch some problems,
but many more slip through these initial checks and it is only after the
change is integrated and pushed on orion.eclipse.org and we start self-hosting
that we find the problem. Eventually we might have enough tests that this
becomes a rare event, but currently it is quite common. So far we have
no performance tests, and no page-level integration tests for the UI. Essentially
this appears to me the same as Anthony's "never introduce bugs in
master" proposal, which is great in theory, but until we are consistently
doing that it is not sufficient.
<br><br>Having said that, if we can get the
Gerrit workflows working in Orion, together with automated build &amp;
test for uploaded patches, I'm sure it would help us to reduce the number
of bugs introduced and might get us to the point where we no longer need
a stable branch.
<br><br>John
<br><br><br><br><br>From: &nbsp; &nbsp; &nbsp;
&nbsp;Matthias Sohn &lt;matthias.sohn@...&gt;
<br>To: &nbsp; &nbsp; &nbsp;
&nbsp;Orion developer discussions
&lt;orion-dev@...&gt;, 
<br>Date: &nbsp; &nbsp; &nbsp;
&nbsp;07/18/2014 04:11 AM
<br>Subject: &nbsp; &nbsp;
&nbsp; &nbsp;Re: [orion-dev]
Process for converging on stable/release builds
<br>Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;orion-dev-bounces@...
<br><br><br><br>On Thu, Jul 17, 2014 at 7:43 PM, John Arthorne &lt;<a href="mailto:John_Arthorne@..." target="_blank">John_Arthorne@...</a>&gt;
wrote:
<br>During Orion 7.0 we have completely
stopped doing milestones in favour of a more continuous delivery model.
We would like to produce regular (roughly weekly) stable builds that can
be deployed to <a href="http://orionhub.org/" target="_blank">orionhub.org</a>.
One issue with this is how to stabilize the code for a stable build without
disrupting ongoing development in master. After discussing ideas with various
committers I would like to propose a process of branching once per week
at a predictable time, and use that to converge on a stable build while
allowing master branch to continue development. <br><br><a href="https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process" target="_blank">https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process</a>
<br><br>
I have done a test drive of this process this week. I setup new "stable"
build in Hudson that builds from a branch: <br><br><a href="https://hudson.eclipse.org/orion/job/orion-client-stable/" target="_blank">https://hudson.eclipse.org/orion/job/orion-client-stable/</a>
<br><br>
I used this to produced a stable 7.0 S1 (Orion 7 stable build #1) that
I have deployed to <a href="http://orionhub.org/" target="_blank">orionhub.org</a>:
<br><br><a href="http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html" target="_blank">http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html</a>
<br><br>
Committers please take a look at this proposed process and respond here
with any thoughts and concerns.&nbsp;
<br><br>this sounds like a manual implementation of a process
pretty similar to the one supported by Gerrit.
<br>So why don't we adopt the Gerrit code review workflow
instead to reach an always stable master branch ?
<br><br>- Instead of pushing to master everybody would push (all
changes) to refs/for/master
<br>- Gerrit creates a new change / patchset for reviewing
<br>- new change / patchset triggers Hudson to run a build
/ tests
<br>- Hudson votes +1 if build / tests succeed or -1 if build
/tests fail
<br>- other committers / integrator of the week review changes
pending in review and vote
<br>- changes in review which got approved in review are submitted
<br>- Hudson builds / tests resulting new version on master
branch
<br>- if some submitted change turns out to be bad revert
it (to my experience this happens very rarely)
<br><br>--
<br>Matthias&nbsp;_______________________________________________<br>
orion-dev mailing list<br>
orion-dev@...<br>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit<br><a href="https://dev.eclipse.org/mailman/listinfo/orion-dev">https://dev.eclipse.org/mailman/listinfo/orion-dev</a>
<br>
</div>
John Arthorne | 21 Jul 17:09 2014
Picon

[orion-dev] orion.eclipse.org outage

To save anyone else pinging me... orion.eclipse.org is down and I don't know why or how to fix it. Entered this bug for webmaster to help us:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026

I suspect it is related to the wider eclipse.org outage last night.

orionhub.org is fine though ;)

John
<div>To save anyone else pinging me... orion.eclipse.org
is down and I don't know why or how to fix it. Entered this bug for webmaster
to help us:
<br><br><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026">https://bugs.eclipse.org/bugs/show_bug.cgi?id=440026</a>
<br><br>I suspect it is related to the wider
eclipse.org outage last night.
<br><br>orionhub.org is fine though ;)
<br><br>John
<br>
</div>
John Arthorne | 17 Jul 19:43 2014
Picon

[orion-dev] Process for converging on stable/release builds

During Orion 7.0 we have completely stopped doing milestones in favour of a more continuous delivery model. We would like to produce regular (roughly weekly) stable builds that can be deployed to orionhub.org. One issue with this is how to stabilize the code for a stable build without disrupting ongoing development in master. After discussing ideas with various committers I would like to propose a process of branching once per week at a predictable time, and use that to converge on a stable build while allowing master branch to continue development.

https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process

I have done a test drive of this process this week. I setup new "stable" build in Hudson that builds from a branch:

https://hudson.eclipse.org/orion/job/orion-client-stable/

I used this to produced a stable 7.0 S1 (Orion 7 stable build #1) that I have deployed to orionhub.org:

http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html

Committers please take a look at this proposed process and respond here with any thoughts and concerns.

Thanks,
John
<div>During Orion 7.0 we have completely stopped
doing milestones in favour of a more continuous delivery model. We would
like to produce regular (roughly weekly) stable builds that can be deployed
to orionhub.org. One issue with this is how to stabilize the code for a
stable build without disrupting ongoing development in master. After discussing
ideas with various committers I would like to propose a process of branching
once per week at a predictable time, and use that to converge on a stable
build while allowing master branch to continue development. 
<br><br><a href="https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process">https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process</a>
<br><br>I have done a test drive of this process
this week. I setup new "stable" build in Hudson that builds from
a branch:
<br><br><a href="https://hudson.eclipse.org/orion/job/orion-client-stable/">https://hudson.eclipse.org/orion/job/orion-client-stable/</a>
<br><br>I used this to produced a stable 7.0
S1 (Orion 7 stable build #1) that I have deployed to orionhub.org:
<br><br><a href="http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html">http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html</a>
<br><br>Committers please take a look at this
proposed process and respond here with any thoughts and concerns.
<br><br>Thanks,
<br>John
<br>
</div>
Mickaël Leduque | 17 Jul 14:33 2014

[orion-dev] Orion editor height problem

Hi,

I have a strange behaviour of the orion editor (pure javascript editor embedded in a web page). Its height seems to be set to 50px even when the parent element is much bigger.

I didn't find anything in the jsdoc (https://orionhub.org/jsdoc/index.html) that tells me how to have it use the whole space (something like min-height:fill-available). Or maybe to resize itself.

Doe someone have an idea ?

Mickaël
<div><div dir="ltr">
<div>
<div>
<div>
<div>Hi,<br><br>
</div>I have a strange behaviour of the orion editor (pure javascript editor embedded in a web page). Its height seems to be set to 50px even when the parent element is much bigger.<br><br>
</div>I didn't find anything in the jsdoc (<a href="https://orionhub.org/jsdoc/index.html">https://orionhub.org/jsdoc/index.html</a>) that tells me how to have it use the whole space (something like min-height:fill-available). Or maybe to resize itself.<br><br>
</div>Doe someone have an idea ?<br><br>
</div>Micka&euml;l<br>
</div></div>
John Arthorne | 16 Jul 17:26 2014
Picon

[orion-dev] Orion Scalability

The current state of Orion Java server scalability is that it scales reasonably well on the large instances we know about, which have 20-30K users, up to 500 active users on a given day, and up to 600 GB of user content. We are planning out the next phase of scalability to enable clusters of Orion servers operating on a few orders of magnitude larger install bases. The following wiki page outlines the work areas we have identified so far, with links to various related work items:

https://wiki.eclipse.org/Orion/Server_scalability

If you have experience with running large scale Orion instances we would love to hear your feedback on scalability issues you are seeing, and of course welcome any participation in the work to take us to the next level...

John
<div>The current state of Orion Java server
scalability is that it scales reasonably well on the large instances we
know about, which have 20-30K users, up to 500 active users on a given
day, and up to 600 GB of user content. We are planning out the next phase
of scalability to enable clusters of Orion servers operating on a few orders
of magnitude larger install bases. The following wiki page outlines the
work areas we have identified so far, with links to various related work
items:
<br><br><a href="https://wiki.eclipse.org/Orion/Server_scalability">https://wiki.eclipse.org/Orion/Server_scalability</a>
<br><br>If you have experience with running
large scale Orion instances we would love to hear your feedback on scalability
issues you are seeing, and of course welcome any participation in the work
to take us to the next level...
<br><br>John
<br>
</div>
Ken Walker | 10 Jul 17:45 2014
Picon

[orion-dev] Meeting minutes for July 10th

https://wiki.eclipse.org/Orion/Meeting_minutes/20140710

Ken Walker
Lead of the Orion Project at Eclipse and within IBM | Tools for the Web, On the Web
https://orionhub.org | http://wiki.eclipse.org/Orion | https://hub.jazz.net
<at> kwalker | <at> orionhub | <at> jazzhub

<div>
<p><a href="https://wiki.eclipse.org/Orion/Meeting_minutes/20140710">https://wiki.eclipse.org/Orion/Meeting_minutes/20140710</a><br><br>Ken Walker<br>
Lead of the Orion Project at Eclipse and within IBM | Tools for the Web, On the Web<br><a href="https://orionhub.org">https://orionhub.org</a> | <a href="http://wiki.eclipse.org/Orion">http://wiki.eclipse.org/Orion</a> | <a href="https://hub.jazz.net">https://hub.jazz.net</a><br>
 <at> kwalker |  <at> orionhub |  <at> jazzhub<br><br></p>
</div>

Gmane