You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Müller <ch...@gmail.com> on 2013/01/16 22:12:47 UTC
[CAMEL-3.0] Start moving forward
I find it very difficult to start a such huge and important challenge as
Camel 3.0 will be, for sure. I think the most difficult part is to get
consensus about what we do it and how we do it. We already collect some
useful ideas at [1], but I have the feeling we have to review these ideas.
First of all, because I don't think we can do all of them in one release (I
also have a few more - more important from my point of view - ideas,
collected from users, contributors, committers and PMC members). Second,
some ideas need more "meat" before someone else than the authors know what
this means and which impact it has. Third, a few of these ideas are already
implemented in Camel 2.11 or before, so that we can remove it from this
page to be more focused.
- Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
- Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
content in the next weeks
- I propose to subdivide this page into three (child) pages:
- What has to be done before we can start working on Camel 3.0 (probably
during the (short term) Camel 2.12)
- What are the changes we do in Camel 3.0
- What is postpone to 3.1 or later
- Afterwards we put everything together, we will see on which ideas we
already agree and which ones requires detailed discussions.
- For later ones I propose a weekly (or two times per week) IRC/Skype
session for discussion (Which days/time fit best for you?)
- We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@ for
the guys they are not able to attend
- Afterwards we will send the results to the dev@ mailing list to share
it (if you are interested in it, join us at dev@camel.apache.org)
I will start with it after 72 h to give everyone the possibility to suggest
another approach (I will only start writing down some ideas which are not
on table right now). And of course, every help is welcome. A simple -1 or
better +1 ;-) is not much, but also helpful and better than no feedback...
Better, if you join us [2] and ride together with us Camel 3.0.
[1] http://camel.apache.org/camel-30-roadmap.html
[2] http://camel.apache.org/contributing.html
Best,
Christian
--
Re: [CAMEL-3.0] Start moving forward
Posted by Willem jiang <wi...@gmail.com>.
Yeah, we need a detail plan and time table for the Camel 3.0.0.
As we have the patch release for the major Camel release, it is make sense to change the Camel version of 3.0.0
BTW, merge the patches into three different branches makes us have less time to think about the new version of Camel, I'd like to suggest we only support Camel 2.11.x when we doing the Camel 3.0.0 development.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Thursday, January 17, 2013 at 5:12 AM, Christian Müller wrote:
> I find it very difficult to start a such huge and important challenge as
> Camel 3.0 will be, for sure. I think the most difficult part is to get
> consensus about what we do it and how we do it. We already collect some
> useful ideas at [1], but I have the feeling we have to review these ideas.
> First of all, because I don't think we can do all of them in one release (I
> also have a few more - more important from my point of view - ideas,
> collected from users, contributors, committers and PMC members). Second,
> some ideas need more "meat" before someone else than the authors know what
> this means and which impact it has. Third, a few of these ideas are already
> implemented in Camel 2.11 or before, so that we can remove it from this
> page to be more focused.
>
> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>
> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> content in the next weeks
> - I propose to subdivide this page into three (child) pages:
> - What has to be done before we can start working on Camel 3.0 (probably
> during the (short term) Camel 2.12)
> - What are the changes we do in Camel 3.0
> - What is postpone to 3.1 or later
> - Afterwards we put everything together, we will see on which ideas we
> already agree and which ones requires detailed discussions.
> - For later ones I propose a weekly (or two times per week) IRC/Skype
> session for discussion (Which days/time fit best for you?)
> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@ for
> the guys they are not able to attend
> - Afterwards we will send the results to the dev@ mailing list to share
> it (if you are interested in it, join us at dev@camel.apache.org (mailto:dev@camel.apache.org))
>
> I will start with it after 72 h to give everyone the possibility to suggest
> another approach (I will only start writing down some ideas which are not
> on table right now). And of course, every help is welcome. A simple -1 or
> better +1 ;-) is not much, but also helpful and better than no feedback...
> Better, if you join us [2] and ride together with us Camel 3.0.
>
> [1] http://camel.apache.org/camel-30-roadmap.html
> [2] http://camel.apache.org/contributing.html
>
> Best,
> Christian
>
> --
Re: [CAMEL-3.0] Start moving forward
Posted by Guillaume Nodet <gn...@gmail.com>.
For the webconsole, I'd make sure to have a look at http://hawt.io/
On Wed, Jan 23, 2013 at 11:03 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> Lukasz, could you have a look at [1]!?
> We are looking for a champion for the task "Light-weight web console" (if
> it has enough endorsements). If I remember right, you are playing with
> something what could be this light-weight web console. ;-)
> Do you consider to take a stab on this?
>
> [1] http://camel.apache.org/camel-30-ideas.html
>
> Best,
> Christian
>
> On Wed, Jan 23, 2013 at 1:27 PM, Babak Vahdat
> <ba...@swissonline.ch>wrote:
>
> > Hi
> >
> > As much as the time permits I will try to follow this move and maybe give
> > my
> > ideas & feedback to the cool new enhancements/features you are thinking
> > about. However my involvement in this area will not be as active as many
> > others.
> >
> > Looking forward to Camel 3.0
> >
> > Babak
> >
> >
> >
> > --
> > View this message in context:
> >
> http://camel.465427.n5.nabble.com/CAMEL-3-0-Start-moving-forward-tp5725663p5726055.html
> > Sent from the Camel Development mailing list archive at Nabble.com.
> >
>
>
>
> --
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [CAMEL-3.0] Start moving forward
Posted by Guillaume Nodet <gn...@gmail.com>.
I think one of the most interesting part of hawtio is that the same console
can be used in OSGi or in a non-OSGi environment and that's is pluggable
with dynamic discovery. That's really what we needed for years, back to
the ServiceMix 4 early stage.
Having a single console that can adapt multiple deployment environments is
really a must-have and that was the problem so far with the current
console: we have an activemq and a camel console that work on their own,
and a karaf / felix console that only work in OSGi. Having the possibility
to unify those is really AWESOME !!!
On Fri, Jan 25, 2013 at 10:48 AM, Charles Moulliard <ch...@gmail.com>wrote:
> - Will check more in depth next week hawt.io and have a look to your
> remarks.
> - For sure, hawt.io should be the house about camel webconsole and I would
> appreciate that everybody fully agree about that idea instead of
> continuying to re-invent new webconsole every next major realease of Camel.
> - Pertinent remark about command shell and karaf. We will continue this
> discussion within Karaf project
>
>
>
>
> On Fri, Jan 25, 2013 at 10:05 AM, James Strachan
> <ja...@gmail.com>wrote:
>
> > On 25 January 2013 08:07, Charles Moulliard <ch...@gmail.com> wrote:
> > > +1 for the project plan and if you are interested I can play the role
> of
> > > Project Manager to coordinate all the different tasks, actions, define
> a
> > > plan and
> > > following
> > > manage it
> > >
> > > Concerning the webconsole, http://hawt.io project should be the way to
> > go
> > > (or at least jolokia - http://jolokia.org/ ) even if until now the
> code
> > is
> > > too much javascript, typescript oriented (at my opinion).
> >
> > You can write hawtio plugins in anything that compiles-to-JS. So use
> > pure JS, CoffeeScript, EcmaScript6-transpiler, TypeScript, GWT,
> > Kotlin, Ceylon, ClojureScript, ScalaJS or any of the other languages
> > that compile to JS:
> > http://altjs.org/
> >
> > So take your pick; the person who creates a hawtio plugin can use
> > whatever language they prefer; so get cracking Charles on a new plugin
> > and you can use your preferred language! :)
> >
> > The only real APIs a plugin needs to worry about are AngularJS (if you
> > want to work in the core layout rather than just be an iframe), JSON
> > for some pretty trivial extension points like adding new tabs and HTML
> > & CSS. We'll probably move to something like RequireJS for dynamic
> > module loading at some point; but thats pretty language agnostic
> > anyway.
> >
> >
> > > Nevertheless, the webconsole project for Camel should be designed as
> > > pluggable, REST based,
> > > most probably synchronized with also commands that
> > > we have in Karaf (to avoid to duplicate code), packaged as a WAR
> > deployable
> > > in any Java container (Tomcat, TomEE, Jetty, JEE, Karaf).
> >
> > That describes hawtio pretty well already. Now we've got hawtio I'm
> > not sure why we need another web console project?
> >
> > The missing bit is reusing karaf commands easily in a web console (as
> > they are text console based which isn't ideal); ideally we'd be able
> > to introduce an 'object layer' within the commands so that they can
> > expose JSON objects before they are turned into text console strings -
> > so that a web UI can provide a richer visualisation.
> >
> > e.g. check the comments on this issue - in particular try watching the
> > TermKit demo videos to show the kinds of things a command shell could
> > look like in a browser...
> > https://github.com/hawtio/hawtio/issues/17
> >
> > Though the karaf commands are discussion for the karaf project.
> >
> > --
> > James
> > -------
> > Red Hat
> >
> > Email: jstracha@redhat.com
> > Web: http://fusesource.com
> > Twitter: jstrachan, fusenews
> > Blog: http://macstrac.blogspot.com/
> >
> > Open Source Integration
> >
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [CAMEL-3.0] Start moving forward
Posted by Charles Moulliard <ch...@gmail.com>.
- Will check more in depth next week hawt.io and have a look to your
remarks.
- For sure, hawt.io should be the house about camel webconsole and I would
appreciate that everybody fully agree about that idea instead of
continuying to re-invent new webconsole every next major realease of Camel.
- Pertinent remark about command shell and karaf. We will continue this
discussion within Karaf project
On Fri, Jan 25, 2013 at 10:05 AM, James Strachan
<ja...@gmail.com>wrote:
> On 25 January 2013 08:07, Charles Moulliard <ch...@gmail.com> wrote:
> > +1 for the project plan and if you are interested I can play the role of
> > Project Manager to coordinate all the different tasks, actions, define a
> > plan and
> > following
> > manage it
> >
> > Concerning the webconsole, http://hawt.io project should be the way to
> go
> > (or at least jolokia - http://jolokia.org/ ) even if until now the code
> is
> > too much javascript, typescript oriented (at my opinion).
>
> You can write hawtio plugins in anything that compiles-to-JS. So use
> pure JS, CoffeeScript, EcmaScript6-transpiler, TypeScript, GWT,
> Kotlin, Ceylon, ClojureScript, ScalaJS or any of the other languages
> that compile to JS:
> http://altjs.org/
>
> So take your pick; the person who creates a hawtio plugin can use
> whatever language they prefer; so get cracking Charles on a new plugin
> and you can use your preferred language! :)
>
> The only real APIs a plugin needs to worry about are AngularJS (if you
> want to work in the core layout rather than just be an iframe), JSON
> for some pretty trivial extension points like adding new tabs and HTML
> & CSS. We'll probably move to something like RequireJS for dynamic
> module loading at some point; but thats pretty language agnostic
> anyway.
>
>
> > Nevertheless, the webconsole project for Camel should be designed as
> > pluggable, REST based,
> > most probably synchronized with also commands that
> > we have in Karaf (to avoid to duplicate code), packaged as a WAR
> deployable
> > in any Java container (Tomcat, TomEE, Jetty, JEE, Karaf).
>
> That describes hawtio pretty well already. Now we've got hawtio I'm
> not sure why we need another web console project?
>
> The missing bit is reusing karaf commands easily in a web console (as
> they are text console based which isn't ideal); ideally we'd be able
> to introduce an 'object layer' within the commands so that they can
> expose JSON objects before they are turned into text console strings -
> so that a web UI can provide a richer visualisation.
>
> e.g. check the comments on this issue - in particular try watching the
> TermKit demo videos to show the kinds of things a command shell could
> look like in a browser...
> https://github.com/hawtio/hawtio/issues/17
>
> Though the karaf commands are discussion for the karaf project.
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: [CAMEL-3.0] Start moving forward
Posted by James Strachan <ja...@gmail.com>.
On 25 January 2013 08:07, Charles Moulliard <ch...@gmail.com> wrote:
> +1 for the project plan and if you are interested I can play the role of
> Project Manager to coordinate all the different tasks, actions, define a
> plan and
> following
> manage it
>
> Concerning the webconsole, http://hawt.io project should be the way to go
> (or at least jolokia - http://jolokia.org/ ) even if until now the code is
> too much javascript, typescript oriented (at my opinion).
You can write hawtio plugins in anything that compiles-to-JS. So use
pure JS, CoffeeScript, EcmaScript6-transpiler, TypeScript, GWT,
Kotlin, Ceylon, ClojureScript, ScalaJS or any of the other languages
that compile to JS:
http://altjs.org/
So take your pick; the person who creates a hawtio plugin can use
whatever language they prefer; so get cracking Charles on a new plugin
and you can use your preferred language! :)
The only real APIs a plugin needs to worry about are AngularJS (if you
want to work in the core layout rather than just be an iframe), JSON
for some pretty trivial extension points like adding new tabs and HTML
& CSS. We'll probably move to something like RequireJS for dynamic
module loading at some point; but thats pretty language agnostic
anyway.
> Nevertheless, the webconsole project for Camel should be designed as
> pluggable, REST based,
> most probably synchronized with also commands that
> we have in Karaf (to avoid to duplicate code), packaged as a WAR deployable
> in any Java container (Tomcat, TomEE, Jetty, JEE, Karaf).
That describes hawtio pretty well already. Now we've got hawtio I'm
not sure why we need another web console project?
The missing bit is reusing karaf commands easily in a web console (as
they are text console based which isn't ideal); ideally we'd be able
to introduce an 'object layer' within the commands so that they can
expose JSON objects before they are turned into text console strings -
so that a web UI can provide a richer visualisation.
e.g. check the comments on this issue - in particular try watching the
TermKit demo videos to show the kinds of things a command shell could
look like in a browser...
https://github.com/hawtio/hawtio/issues/17
Though the karaf commands are discussion for the karaf project.
--
James
-------
Red Hat
Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
Re: [CAMEL-3.0] Start moving forward
Posted by Charles Moulliard <ch...@gmail.com>.
+1 for the project plan and if you are interested I can play the role of
Project Manager to coordinate all the different tasks, actions, define a
plan and
following
manage it
Concerning the webconsole, http://hawt.io project should be the way to go
(or at least jolokia - http://jolokia.org/ ) even if until now the code is
too much javascript, typescript oriented (at my opinion).
Nevertheless, the webconsole project for Camel should be designed as
pluggable, REST based, most probably synchronized with also commands that
we have in Karaf (to avoid to duplicate code), packaged as a WAR deployable
in any Java container (Tomcat, TomEE, Jetty, JEE, Karaf).
On Wed, Jan 23, 2013 at 11:03 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> Lukasz, could you have a look at [1]!?
> We are looking for a champion for the task "Light-weight web console" (if
> it has enough endorsements). If I remember right, you are playing with
> something what could be this light-weight web console. ;-)
> Do you consider to take a stab on this?
>
> [1] http://camel.apache.org/camel-30-ideas.html
>
> Best,
> Christian
>
> On Wed, Jan 23, 2013 at 1:27 PM, Babak Vahdat
> <ba...@swissonline.ch>wrote:
>
> > Hi
> >
> > As much as the time permits I will try to follow this move and maybe give
> > my
> > ideas & feedback to the cool new enhancements/features you are thinking
> > about. However my involvement in this area will not be as active as many
> > others.
> >
> > Looking forward to Camel 3.0
> >
> > Babak
> >
> >
> >
> > --
> > View this message in context:
> >
> http://camel.465427.n5.nabble.com/CAMEL-3-0-Start-moving-forward-tp5725663p5726055.html
> > Sent from the Camel Development mailing list archive at Nabble.com.
> >
>
>
>
> --
>
--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: [CAMEL-3.0] Start moving forward
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Anybody. We need to hear the ideas of even non-committers actually.
However if there are enough endorsements I'd think there is no need to
add another one. What is more important is to see if anybody has
anything against an idea and what kind of arguments he'd bring to the table.
Hadrian
On 01/24/2013 05:22 PM, Henryk Konsek wrote:
>> (if
>> it has enough endorsements).
>
> Talking about endorsements... Can all committers endorse or is this
> privilege reserved for the PMC masonic lodge? :)
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: [CAMEL-3.0] Start moving forward
Posted by Henryk Konsek <he...@gmail.com>.
> (if
> it has enough endorsements).
Talking about endorsements... Can all committers endorse or is this
privilege reserved for the PMC masonic lodge? :)
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [CAMEL-3.0] Start moving forward
Posted by Christian Müller <ch...@gmail.com>.
Lukasz, could you have a look at [1]!?
We are looking for a champion for the task "Light-weight web console" (if
it has enough endorsements). If I remember right, you are playing with
something what could be this light-weight web console. ;-)
Do you consider to take a stab on this?
[1] http://camel.apache.org/camel-30-ideas.html
Best,
Christian
On Wed, Jan 23, 2013 at 1:27 PM, Babak Vahdat
<ba...@swissonline.ch>wrote:
> Hi
>
> As much as the time permits I will try to follow this move and maybe give
> my
> ideas & feedback to the cool new enhancements/features you are thinking
> about. However my involvement in this area will not be as active as many
> others.
>
> Looking forward to Camel 3.0
>
> Babak
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CAMEL-3-0-Start-moving-forward-tp5725663p5726055.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Re: [CAMEL-3.0] Start moving forward
Posted by Christian Müller <ch...@gmail.com>.
Christian, could you have a look at [1]!?
We are looking for a champion for the task "Split camel-core into multiple
parts". We already talked about it in the past and if I remember correct,
you are willing to take a stab on this. Right? Still the same?
[1] http://camel.apache.org/camel-30-ideas.html
Best,
Christian
On Wed, Jan 23, 2013 at 1:27 PM, Babak Vahdat
<ba...@swissonline.ch>wrote:
> Hi
>
> As much as the time permits I will try to follow this move and maybe give
> my
> ideas & feedback to the cool new enhancements/features you are thinking
> about. However my involvement in this area will not be as active as many
> others.
>
> Looking forward to Camel 3.0
>
> Babak
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CAMEL-3-0-Start-moving-forward-tp5725663p5726055.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Re: [CAMEL-3.0] Start moving forward
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
As much as the time permits I will try to follow this move and maybe give my
ideas & feedback to the cool new enhancements/features you are thinking
about. However my involvement in this area will not be as active as many
others.
Looking forward to Camel 3.0
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/CAMEL-3-0-Start-moving-forward-tp5725663p5726055.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [CAMEL-3.0] Start moving forward
Posted by Henryk Konsek <he...@gmail.com>.
> +1 for having discussion on mailing list.
Oh, and the idea with separated wiki pages - just great :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [CAMEL-3.0] Start moving forward
Posted by Henryk Konsek <he...@gmail.com>.
> Discussions *should* happen on the @dev mailing list, so everybody can
> be in the loop and participate.
> Its the Apache way.
+1 for having discussion on mailing list.
Not only due to the fact that I want to be in the loop, but also
because the discussion should be "googlable" for users interested in
the reasoning behind the direction of Camel development.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [CAMEL-3.0] Start moving forward
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Oh been too busy with work, than having the time to read this thread
and respond.
On Wed, Jan 16, 2013 at 10:12 PM, Christian Müller
<ch...@gmail.com> wrote:
> I find it very difficult to start a such huge and important challenge as
> Camel 3.0 will be, for sure. I think the most difficult part is to get
> consensus about what we do it and how we do it. We already collect some
> useful ideas at [1], but I have the feeling we have to review these ideas.
> First of all, because I don't think we can do all of them in one release (I
> also have a few more - more important from my point of view - ideas,
> collected from users, contributors, committers and PMC members). Second,
> some ideas need more "meat" before someone else than the authors know what
> this means and which impact it has. Third, a few of these ideas are already
> implemented in Camel 2.11 or before, so that we can remove it from this
> page to be more focused.
>
> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>
Yeah good idea to rename it to "ideas" as that page was frankly just
ideas we have
noted down over the time for possible inclusion in Camel 3.x.
> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> content in the next weeks
> - I propose to subdivide this page into three (child) pages:
> - What has to be done before we can start working on Camel 3.0 (probably
> during the (short term) Camel 2.12)
> - What are the changes we do in Camel 3.0
> - What is postpone to 3.1 or later
> - Afterwards we put everything together, we will see on which ideas we
> already agree and which ones requires detailed discussions.
Yeah having a new 3.0 roadmap page is a good idea.
And another page for ideas for the future. Though I suggest to not tie
that into 3.1 etc.
Just for the future eg in the 3.x timeframe.
> - For later ones I propose a weekly (or two times per week) IRC/Skype
> session for discussion (Which days/time fit best for you?)
> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@ for
> the guys they are not able to attend
> - Afterwards we will send the results to the dev@ mailing list to share
> it (if you are interested in it, join us at dev@camel.apache.org)
>
Discussions *should* happen on the @dev mailing list, so everybody can
be in the loop and participate.
Its the Apache way.
> I will start with it after 72 h to give everyone the possibility to suggest
> another approach (I will only start writing down some ideas which are not
> on table right now). And of course, every help is welcome. A simple -1 or
> better +1 ;-) is not much, but also helpful and better than no feedback...
> Better, if you join us [2] and ride together with us Camel 3.0.
>
Frankly with the work load and what else people do in their daily job, they
may not have the time to give their feedback and thoughts about this
if the timeframe is as low as 72 hours. I barely had the time to do so.
Though as I guess no final decisions is made within this time.
I see no issue wit starting the work with the wiki pages.
That should be ongoing for some time, so all have had the
amble time to give their feedback.
> [1] http://camel.apache.org/camel-30-roadmap.html
> [2] http://camel.apache.org/contributing.html
>
> Best,
> Christian
>
> --
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Fwd: Re: [CAMEL-3.0] Start moving forward
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hmm, why did this go to users? Because Christian sent it to 3 lists.
Both me and Willem only replied to users@ :). Oops. Let's just use dev@
going forward.
Hadrian
-------- Original Message --------
Subject: Re: [CAMEL-3.0] Start moving forward
Date: Thu, 17 Jan 2013 08:47:11 -0500
From: Hadrian Zbarcea <hz...@gmail.com>
To: users@camel.apache.org
Christian,
Thanks for taking the initiative and restarting the process for Camel
3.0. The good news imho is that we're under no pressure and we can take
the time to get it right.
I like your proposal of effectively splitting the camel-3.0-roadmap page
into multiple pages. If I understand correctly you are suggesting the
following:
- proposals should go on the [ideas] wiki and the discussions on the
mailing lists would refer to the wiki
- the [ideas] page should only contain items currently under discussion
- accepted ideas should move to one of the [roadmap] pages
- keep separate [roadmap] pages for changes to be implemented in
[2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
The goal is to move faster and to avoid votes except in highly
contentious situations which we hope to avoid. I think that would work.
I also think that have an open concall on irc (plus maybe other channel)
at a scheduled time would be great, although hard to accommodate the
time zones.
I would add the following:
1. The ideas on the [ideas] page should be short, containing just an
abstract. If it takes more than that the details should go in a separate
[discuss] thread or another page.
2. Keep [discuss] threads focused on one topic only
3. Use endorsements (e.g. username or initials like [hadrian]) to show
support for an idea (or [-1 hadrian] for a negative endorsement)
4. Once an idea has enough endorsements (3-5, dunno, need to agree on
something) and no negative endorsement for at least say 72 hours or
more, we move it to a [roadmap] page.
5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
6. I am also thinking that each accepted idea on the [roadmap] should
have a champion (not necessarily to implement/commit the code, but stay
on top of it)
If no objections within 3 hours I will get to organizing the pages.
In terms of concrete development, Guillaume had a very interesting
proposal at ACEU in November. We discussed concrete ways of refactoring
the api and realized that it's very hard to fully explain an idea
without showing some code and it's even harder to grasp the consequences
without experimenting a bit with the code. We talked about doing that
either in a (1) separate, possibly github, repo, (2) on a branch or (3)
in the sandbox. This would have the advantage of being able to show an
fast idea without concern for backward compatibility and all. More I
thought about it, more I liked the approach. Of the three alternatives,
the one I like the most is (3), I guess.
To anticipate objections (miscommunication will happen no matter how
hard we'll try) backward compatibility and easy, painless migration are
major goals for 3.0, I would assume everybody agrees. The ways to get
there are many though.
Thoughts?
Hadrian
On 01/16/2013 04:12 PM, Christian Müller wrote:
> I find it very difficult to start a such huge and important challenge as
> Camel 3.0 will be, for sure. I think the most difficult part is to get
> consensus about what we do it and how we do it. We already collect some
> useful ideas at [1], but I have the feeling we have to review these ideas.
> First of all, because I don't think we can do all of them in one release (I
> also have a few more - more important from my point of view - ideas,
> collected from users, contributors, committers and PMC members). Second,
> some ideas need more "meat" before someone else than the authors know what
> this means and which impact it has. Third, a few of these ideas are already
> implemented in Camel 2.11 or before, so that we can remove it from this
> page to be more focused.
>
> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>
> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> content in the next weeks
> - I propose to subdivide this page into three (child) pages:
> - What has to be done before we can start working on Camel 3.0 (probably
> during the (short term) Camel 2.12)
> - What are the changes we do in Camel 3.0
> - What is postpone to 3.1 or later
> - Afterwards we put everything together, we will see on which ideas we
> already agree and which ones requires detailed discussions.
> - For later ones I propose a weekly (or two times per week) IRC/Skype
> session for discussion (Which days/time fit best for you?)
> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@ for
> the guys they are not able to attend
> - Afterwards we will send the results to the dev@ mailing list to share
> it (if you are interested in it, join us at dev@camel.apache.org)
>
> I will start with it after 72 h to give everyone the possibility to suggest
> another approach (I will only start writing down some ideas which are not
> on table right now). And of course, every help is welcome. A simple -1 or
> better +1 ;-) is not much, but also helpful and better than no feedback...
> Better, if you join us [2] and ride together with us Camel 3.0.
>
> [1] http://camel.apache.org/camel-30-roadmap.html
> [2] http://camel.apache.org/contributing.html
>
> Best,
> Christian
>
> --
>
Re: [CAMEL-3.0] Start moving forward
Posted by Willem jiang <wi...@gmail.com>.
I'm OK for the discussion in the IRC and post the discussion back to dev list so every one have a chance to express his opinion.
And we made decision in the mailing list.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, January 22, 2013 at 11:14 AM, Hadrian Zbarcea wrote:
> Willem, yeah it's tough with your time zone, but you can find many of us
> on irc at various time. And btw, your statement that it's "not an Apache
> Way" is not quite accurate. The channel is logged and the relevant
> content of the discuss (and/or link) will be posted on dev@ anyway. The
> Apache Way is to have an open decision making process. And from what I
> understand what Christian proposed is exactly that. More precisely,
> those interested/available can have discussions on irc (or other
> channels, including private), decisions are still be made on the dev@
> list and results posted on the wiki.
>
> Cheers,
> Hadrian
>
> On 01/21/2013 08:17 PM, Willem jiang wrote:
> > Hi Christian
> >
> > Just one comments for the meeting in IRC.
> > It is not an Apache Way to make decision through the IRC.
> > As you know the time you chose is the middle night (3 AM) in my timezone.
> >
> > Maybe we can drop a discussion lines in the wiki page, so every one who wants to join the discussion can have the same page to look in. It could be helpful to past the IRC talk into the wiki page at the same time.
> >
> >
> > --
> > Willem Jiang
> >
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> > Web: http://www.fusesource.com | http://www.redhat.com
> > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
> > http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> >
> >
> >
> > On Tuesday, January 22, 2013 at 5:34 AM, Christian Müller wrote:
> >
> > > Hi Hadrian!
> > >
> > > Please find my comments inline.
> > >
> > > Best,
> > > Christian
> > >
> > > On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbarcea@gmail.com (mailto:hzbarcea@gmail.com)> wrote:
> > >
> > > > Christian,
> > > >
> > > > Thanks for taking the initiative and restarting the process for Camel 3.0.
> > > > The good news imho is that we're under no pressure and we can take the time
> > > > to get it right.
> > >
> > >
> > >
> > >
> > > Right.
> > >
> > > >
> > > > I like your proposal of effectively splitting the camel-3.0-roadmap page
> > > > into multiple pages. If I understand correctly you are suggesting the
> > > > following:
> > > > - proposals should go on the [ideas] wiki and the discussions on the
> > > > mailing lists would refer to the wiki
> > > > - the [ideas] page should only contain items currently under discussion
> > > > - accepted ideas should move to one of the [roadmap] pages
> > > > - keep separate [roadmap] pages for changes to be implemented in
> > > > [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
> > >
> > >
> > >
> > >
> > > Absolute correct.
> > >
> > > >
> > > > The goal is to move faster and to avoid votes except in highly contentious
> > > > situations which we hope to avoid. I think that would work. I also think
> > > > that have an open concall on irc (plus maybe other channel) at a scheduled
> > > > time would be great, although hard to accommodate the time zones.
> > >
> > >
> > >
> > >
> > > Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
> > > I'm open for others if someone has issues with this (starting tomorrow). I
> > > propose we use our normal IRC chat room at irc://irc.codehaus.org/camel (http://irc.codehaus.org/camel) and
> > > see how it works. Using IRC has the advantage of easy publishing the chat
> > > at dev@ after.
> > >
> > > >
> > > > I would add the following:
> > > > 1. The ideas on the [ideas] page should be short, containing just an
> > > > abstract. If it takes more than that the details should go in a separate
> > > > [discuss] thread or another page.
> > >
> > >
> > >
> > >
> > > Do you think we should go ahead and endorse on the ideas page? Otherwise I
> > > will start some [DISCUSS] threads for the ideas I will promote.
> > >
> > >
> > > > 2. Keep [discuss] threads focused on one topic only
> > > > 3. Use endorsements (e.g. username or initials like [hadrian]) to show
> > > > support for an idea (or [-1 hadrian] for a negative endorsement)
> > >
> > >
> > >
> > >
> > > Good idea. I updated the new Roadmap page.
> > >
> > > > 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
> > > > something) and no negative endorsement for at least say 72 hours or more,
> > > > we move it to a [roadmap] page.
> > > > 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
> > > > 6. I am also thinking that each accepted idea on the [roadmap] should have
> > > > a champion (not necessarily to implement/commit the code, but stay on top
> > > > of it)
> > > >
> > > > If no objections within 3 hours I will get to organizing the pages.
> > > Thanks for the initial work.
> > >
> > > >
> > > > In terms of concrete development, Guillaume had a very interesting
> > > > proposal at ACEU in November. We discussed concrete ways of refactoring the
> > > > api and realized that it's very hard to fully explain an idea without
> > > > showing some code and it's even harder to grasp the consequences without
> > > > experimenting a bit with the code. We talked about doing that either in a
> > > > (1) separate, possibly github, repo, (2) on a branch or (3) in the sandbox.
> > > > This would have the advantage of being able to show an fast idea without
> > > > concern for backward compatibility and all. More I thought about it, more I
> > > > liked the approach. Of the three alternatives, the one I like the most is
> > > > (3), I guess.
> > >
> > >
> > >
> > >
> > > If we can have multiple sandboxes for different ideas, +1.
> > >
> > > To anticipate objections (miscommunication will happen no matter how hard
> > > > we'll try) backward compatibility and easy, painless migration are major
> > > > goals for 3.0, I would assume everybody agrees. The ways to get there are
> > > > many though.
> > > >
> > > > Thoughts?
> > > > Hadrian
> > > >
> > > >
> > > >
> > > > On 01/16/2013 04:12 PM, Christian Müller wrote:
> > > >
> > > > > I find it very difficult to start a such huge and important challenge as
> > > > > Camel 3.0 will be, for sure. I think the most difficult part is to get
> > > > > consensus about what we do it and how we do it. We already collect some
> > > > > useful ideas at [1], but I have the feeling we have to review these ideas.
> > > > > First of all, because I don't think we can do all of them in one release
> > > > > (I
> > > > > also have a few more - more important from my point of view - ideas,
> > > > > collected from users, contributors, committers and PMC members). Second,
> > > > > some ideas need more "meat" before someone else than the authors know what
> > > > > this means and which impact it has. Third, a few of these ideas are
> > > > > already
> > > > > implemented in Camel 2.11 or before, so that we can remove it from this
> > > > > page to be more focused.
> > > > >
> > > > > - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
> > > > >
> > > > > - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> > > > > content in the next weeks
> > > > > - I propose to subdivide this page into three (child) pages:
> > > > > - What has to be done before we can start working on Camel 3.0
> > > > > (probably
> > > > > during the (short term) Camel 2.12)
> > > > > - What are the changes we do in Camel 3.0
> > > > > - What is postpone to 3.1 or later
> > > > > - Afterwards we put everything together, we will see on which ideas we
> > > > > already agree and which ones requires detailed discussions.
> > > > > - For later ones I propose a weekly (or two times per week) IRC/Skype
> > > > > session for discussion (Which days/time fit best for you?)
> > > > > - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@for
> > > > > the guys they are not able to attend
> > > > > - Afterwards we will send the results to the dev@ mailing list to
> > > > > share
> > > > > it (if you are interested in it, join us at dev@camel.apache.org (mailto:dev@camel.apache.org))
> > > > >
> > > > > I will start with it after 72 h to give everyone the possibility to
> > > > > suggest
> > > > > another approach (I will only start writing down some ideas which are not
> > > > > on table right now). And of course, every help is welcome. A simple -1 or
> > > > > better +1 ;-) is not much, but also helpful and better than no feedback...
> > > > > Better, if you join us [2] and ride together with us Camel 3.0.
> > > > >
> > > > > [1] http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>
> > > > > [2] http://camel.apache.org/**contributing.html<http://camel.apache.org/contributing.html>
> > > > >
> > > > > Best,
> > > > > Christian
> > > > >
> > > > > --
> > >
> > >
> > > --
Re: [CAMEL-3.0] Start moving forward
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Willem, yeah it's tough with your time zone, but you can find many of us
on irc at various time. And btw, your statement that it's "not an Apache
Way" is not quite accurate. The channel is logged and the relevant
content of the discuss (and/or link) will be posted on dev@ anyway. The
Apache Way is to have an open decision making process. And from what I
understand what Christian proposed is exactly that. More precisely,
those interested/available can have discussions on irc (or other
channels, including private), decisions are still be made on the dev@
list and results posted on the wiki.
Cheers,
Hadrian
On 01/21/2013 08:17 PM, Willem jiang wrote:
> Hi Christian
>
> Just one comments for the meeting in IRC.
> It is not an Apache Way to make decision through the IRC.
> As you know the time you chose is the middle night (3 AM) in my timezone.
>
> Maybe we can drop a discussion lines in the wiki page, so every one who wants to join the discussion can have the same page to look in. It could be helpful to past the IRC talk into the wiki page at the same time.
>
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://www.fusesource.com | http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
>
>
> On Tuesday, January 22, 2013 at 5:34 AM, Christian Müller wrote:
>
>> Hi Hadrian!
>>
>> Please find my comments inline.
>>
>> Best,
>> Christian
>>
>> On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbarcea@gmail.com (mailto:hzbarcea@gmail.com)> wrote:
>>
>>> Christian,
>>>
>>> Thanks for taking the initiative and restarting the process for Camel 3.0.
>>> The good news imho is that we're under no pressure and we can take the time
>>> to get it right.
>>
>>
>> Right.
>>
>>>
>>> I like your proposal of effectively splitting the camel-3.0-roadmap page
>>> into multiple pages. If I understand correctly you are suggesting the
>>> following:
>>> - proposals should go on the [ideas] wiki and the discussions on the
>>> mailing lists would refer to the wiki
>>> - the [ideas] page should only contain items currently under discussion
>>> - accepted ideas should move to one of the [roadmap] pages
>>> - keep separate [roadmap] pages for changes to be implemented in
>>> [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
>>
>>
>> Absolute correct.
>>
>>>
>>> The goal is to move faster and to avoid votes except in highly contentious
>>> situations which we hope to avoid. I think that would work. I also think
>>> that have an open concall on irc (plus maybe other channel) at a scheduled
>>> time would be great, although hard to accommodate the time zones.
>>
>>
>> Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
>> I'm open for others if someone has issues with this (starting tomorrow). I
>> propose we use our normal IRC chat room at irc://irc.codehaus.org/camel (http://irc.codehaus.org/camel) and
>> see how it works. Using IRC has the advantage of easy publishing the chat
>> at dev@ after.
>>
>>>
>>> I would add the following:
>>> 1. The ideas on the [ideas] page should be short, containing just an
>>> abstract. If it takes more than that the details should go in a separate
>>> [discuss] thread or another page.
>>
>>
>> Do you think we should go ahead and endorse on the ideas page? Otherwise I
>> will start some [DISCUSS] threads for the ideas I will promote.
>>
>>
>>> 2. Keep [discuss] threads focused on one topic only
>>> 3. Use endorsements (e.g. username or initials like [hadrian]) to show
>>> support for an idea (or [-1 hadrian] for a negative endorsement)
>>
>>
>> Good idea. I updated the new Roadmap page.
>>
>>> 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
>>> something) and no negative endorsement for at least say 72 hours or more,
>>> we move it to a [roadmap] page.
>>> 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
>>> 6. I am also thinking that each accepted idea on the [roadmap] should have
>>> a champion (not necessarily to implement/commit the code, but stay on top
>>> of it)
>>>
>>> If no objections within 3 hours I will get to organizing the pages.
>> Thanks for the initial work.
>>
>>>
>>> In terms of concrete development, Guillaume had a very interesting
>>> proposal at ACEU in November. We discussed concrete ways of refactoring the
>>> api and realized that it's very hard to fully explain an idea without
>>> showing some code and it's even harder to grasp the consequences without
>>> experimenting a bit with the code. We talked about doing that either in a
>>> (1) separate, possibly github, repo, (2) on a branch or (3) in the sandbox.
>>> This would have the advantage of being able to show an fast idea without
>>> concern for backward compatibility and all. More I thought about it, more I
>>> liked the approach. Of the three alternatives, the one I like the most is
>>> (3), I guess.
>>
>>
>> If we can have multiple sandboxes for different ideas, +1.
>>
>> To anticipate objections (miscommunication will happen no matter how hard
>>> we'll try) backward compatibility and easy, painless migration are major
>>> goals for 3.0, I would assume everybody agrees. The ways to get there are
>>> many though.
>>>
>>> Thoughts?
>>> Hadrian
>>>
>>>
>>>
>>> On 01/16/2013 04:12 PM, Christian Müller wrote:
>>>
>>>> I find it very difficult to start a such huge and important challenge as
>>>> Camel 3.0 will be, for sure. I think the most difficult part is to get
>>>> consensus about what we do it and how we do it. We already collect some
>>>> useful ideas at [1], but I have the feeling we have to review these ideas.
>>>> First of all, because I don't think we can do all of them in one release
>>>> (I
>>>> also have a few more - more important from my point of view - ideas,
>>>> collected from users, contributors, committers and PMC members). Second,
>>>> some ideas need more "meat" before someone else than the authors know what
>>>> this means and which impact it has. Third, a few of these ideas are
>>>> already
>>>> implemented in Camel 2.11 or before, so that we can remove it from this
>>>> page to be more focused.
>>>>
>>>> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>>>>
>>>> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
>>>> content in the next weeks
>>>> - I propose to subdivide this page into three (child) pages:
>>>> - What has to be done before we can start working on Camel 3.0
>>>> (probably
>>>> during the (short term) Camel 2.12)
>>>> - What are the changes we do in Camel 3.0
>>>> - What is postpone to 3.1 or later
>>>> - Afterwards we put everything together, we will see on which ideas we
>>>> already agree and which ones requires detailed discussions.
>>>> - For later ones I propose a weekly (or two times per week) IRC/Skype
>>>> session for discussion (Which days/time fit best for you?)
>>>> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@for
>>>> the guys they are not able to attend
>>>> - Afterwards we will send the results to the dev@ mailing list to
>>>> share
>>>> it (if you are interested in it, join us at dev@camel.apache.org (mailto:dev@camel.apache.org))
>>>>
>>>> I will start with it after 72 h to give everyone the possibility to
>>>> suggest
>>>> another approach (I will only start writing down some ideas which are not
>>>> on table right now). And of course, every help is welcome. A simple -1 or
>>>> better +1 ;-) is not much, but also helpful and better than no feedback...
>>>> Better, if you join us [2] and ride together with us Camel 3.0.
>>>>
>>>> [1] http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>
>>>> [2] http://camel.apache.org/**contributing.html<http://camel.apache.org/contributing.html>
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>> --
>>
>>
>> --
>
>
Re: [CAMEL-3.0] Start moving forward
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 22, 2013 at 10:25 PM, Christian Müller
<ch...@gmail.com> wrote:
> Hi Willem,
>
> that's the reason why I wrote "IRC/Skype session for discussion" and not
> "IRC/Skype session to make discussions"... ;-)
> The proposed procedure is to use IRC to be able to discuss multiple topics
> in short time. Afterwards the IRC log and may be a summery should be shared
> with the community (WIKI page, @dev mailing list, ...). After a sufficient
> amount of time (e.g. 72 hours) we can make decisions on the mailing list.
>
> Because of an urgent reason, I couldn't be only today from 7:00 - 8:00 PM.
> But it looks like I didn't miss anything. Work this proposed schedule for
> most of you (every Thursday 7:00 - 8:00 PM)?
>
Yeah I am okat with this time. And I think IRC chat is the best, as we
can log the conversation.
And post it on the @dev for others to see.
> Best,
> Christian
>
> On Tue, Jan 22, 2013 at 2:17 AM, Willem jiang <wi...@gmail.com>wrote:
>
>> Hi Christian
>>
>> Just one comments for the meeting in IRC.
>> It is not an Apache Way to make decision through the IRC.
>> As you know the time you chose is the middle night (3 AM) in my timezone.
>>
>> Maybe we can drop a discussion lines in the wiki page, so every one who
>> wants to join the discussion can have the same page to look in. It could be
>> helpful to past the IRC talk into the wiki page at the same time.
>>
>>
>> --
>> Willem Jiang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://www.fusesource.com | http://www.redhat.com
>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>> (English)
>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>>
>>
>> On Tuesday, January 22, 2013 at 5:34 AM, Christian Müller wrote:
>>
>> > Hi Hadrian!
>> >
>> > Please find my comments inline.
>> >
>> > Best,
>> > Christian
>> >
>> > On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbarcea@gmail.com(mailto:
>> hzbarcea@gmail.com)> wrote:
>> >
>> > > Christian,
>> > >
>> > > Thanks for taking the initiative and restarting the process for Camel
>> 3.0.
>> > > The good news imho is that we're under no pressure and we can take the
>> time
>> > > to get it right.
>> >
>> >
>> > Right.
>> >
>> > >
>> > > I like your proposal of effectively splitting the camel-3.0-roadmap
>> page
>> > > into multiple pages. If I understand correctly you are suggesting the
>> > > following:
>> > > - proposals should go on the [ideas] wiki and the discussions on the
>> > > mailing lists would refer to the wiki
>> > > - the [ideas] page should only contain items currently under discussion
>> > > - accepted ideas should move to one of the [roadmap] pages
>> > > - keep separate [roadmap] pages for changes to be implemented in
>> > > [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
>> >
>> >
>> > Absolute correct.
>> >
>> > >
>> > > The goal is to move faster and to avoid votes except in highly
>> contentious
>> > > situations which we hope to avoid. I think that would work. I also
>> think
>> > > that have an open concall on irc (plus maybe other channel) at a
>> scheduled
>> > > time would be great, although hard to accommodate the time zones.
>> >
>> >
>> > Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
>> > I'm open for others if someone has issues with this (starting tomorrow).
>> I
>> > propose we use our normal IRC chat room at irc://irc.codehaus.org/camel(
>> http://irc.codehaus.org/camel) and
>> > see how it works. Using IRC has the advantage of easy publishing the chat
>> > at dev@ after.
>> >
>> > >
>> > > I would add the following:
>> > > 1. The ideas on the [ideas] page should be short, containing just an
>> > > abstract. If it takes more than that the details should go in a
>> separate
>> > > [discuss] thread or another page.
>> >
>> >
>> > Do you think we should go ahead and endorse on the ideas page? Otherwise
>> I
>> > will start some [DISCUSS] threads for the ideas I will promote.
>> >
>> >
>> > > 2. Keep [discuss] threads focused on one topic only
>> > > 3. Use endorsements (e.g. username or initials like [hadrian]) to show
>> > > support for an idea (or [-1 hadrian] for a negative endorsement)
>> >
>> >
>> > Good idea. I updated the new Roadmap page.
>> >
>> > > 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
>> > > something) and no negative endorsement for at least say 72 hours or
>> more,
>> > > we move it to a [roadmap] page.
>> > > 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
>> > > 6. I am also thinking that each accepted idea on the [roadmap] should
>> have
>> > > a champion (not necessarily to implement/commit the code, but stay on
>> top
>> > > of it)
>> > >
>> > > If no objections within 3 hours I will get to organizing the pages.
>> > Thanks for the initial work.
>> >
>> > >
>> > > In terms of concrete development, Guillaume had a very interesting
>> > > proposal at ACEU in November. We discussed concrete ways of
>> refactoring the
>> > > api and realized that it's very hard to fully explain an idea without
>> > > showing some code and it's even harder to grasp the consequences
>> without
>> > > experimenting a bit with the code. We talked about doing that either
>> in a
>> > > (1) separate, possibly github, repo, (2) on a branch or (3) in the
>> sandbox.
>> > > This would have the advantage of being able to show an fast idea
>> without
>> > > concern for backward compatibility and all. More I thought about it,
>> more I
>> > > liked the approach. Of the three alternatives, the one I like the most
>> is
>> > > (3), I guess.
>> >
>> >
>> > If we can have multiple sandboxes for different ideas, +1.
>> >
>> > To anticipate objections (miscommunication will happen no matter how hard
>> > > we'll try) backward compatibility and easy, painless migration are
>> major
>> > > goals for 3.0, I would assume everybody agrees. The ways to get there
>> are
>> > > many though.
>> > >
>> > > Thoughts?
>> > > Hadrian
>> > >
>> > >
>> > >
>> > > On 01/16/2013 04:12 PM, Christian Müller wrote:
>> > >
>> > > > I find it very difficult to start a such huge and important
>> challenge as
>> > > > Camel 3.0 will be, for sure. I think the most difficult part is to
>> get
>> > > > consensus about what we do it and how we do it. We already collect
>> some
>> > > > useful ideas at [1], but I have the feeling we have to review these
>> ideas.
>> > > > First of all, because I don't think we can do all of them in one
>> release
>> > > > (I
>> > > > also have a few more - more important from my point of view - ideas,
>> > > > collected from users, contributors, committers and PMC members).
>> Second,
>> > > > some ideas need more "meat" before someone else than the authors
>> know what
>> > > > this means and which impact it has. Third, a few of these ideas are
>> > > > already
>> > > > implemented in Camel 2.11 or before, so that we can remove it from
>> this
>> > > > page to be more focused.
>> > > >
>> > > > - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>> > > >
>> > > > - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill
>> with
>> > > > content in the next weeks
>> > > > - I propose to subdivide this page into three (child) pages:
>> > > > - What has to be done before we can start working on Camel 3.0
>> > > > (probably
>> > > > during the (short term) Camel 2.12)
>> > > > - What are the changes we do in Camel 3.0
>> > > > - What is postpone to 3.1 or later
>> > > > - Afterwards we put everything together, we will see on which ideas
>> we
>> > > > already agree and which ones requires detailed discussions.
>> > > > - For later ones I propose a weekly (or two times per week) IRC/Skype
>> > > > session for discussion (Which days/time fit best for you?)
>> > > > - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at
>> dev@for
>> > > > the guys they are not able to attend
>> > > > - Afterwards we will send the results to the dev@ mailing list to
>> > > > share
>> > > > it (if you are interested in it, join us at dev@camel.apache.org(mailto:
>> dev@camel.apache.org))
>> > > >
>> > > > I will start with it after 72 h to give everyone the possibility to
>> > > > suggest
>> > > > another approach (I will only start writing down some ideas which
>> are not
>> > > > on table right now). And of course, every help is welcome. A simple
>> -1 or
>> > > > better +1 ;-) is not much, but also helpful and better than no
>> feedback...
>> > > > Better, if you join us [2] and ride together with us Camel 3.0.
>> > > >
>> > > > [1] http://camel.apache.org/camel-**30-roadmap.html<
>> http://camel.apache.org/camel-30-roadmap.html>
>> > > > [2] http://camel.apache.org/**contributing.html<
>> http://camel.apache.org/contributing.html>
>> > > >
>> > > > Best,
>> > > > Christian
>> > > >
>> > > > --
>> >
>> >
>> > --
>>
>>
>>
>
>
> --
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [CAMEL-3.0] Start moving forward
Posted by Christian Müller <ch...@gmail.com>.
Hi Willem,
that's the reason why I wrote "IRC/Skype session for discussion" and not
"IRC/Skype session to make discussions"... ;-)
The proposed procedure is to use IRC to be able to discuss multiple topics
in short time. Afterwards the IRC log and may be a summery should be shared
with the community (WIKI page, @dev mailing list, ...). After a sufficient
amount of time (e.g. 72 hours) we can make decisions on the mailing list.
Because of an urgent reason, I couldn't be only today from 7:00 - 8:00 PM.
But it looks like I didn't miss anything. Work this proposed schedule for
most of you (every Thursday 7:00 - 8:00 PM)?
Best,
Christian
On Tue, Jan 22, 2013 at 2:17 AM, Willem jiang <wi...@gmail.com>wrote:
> Hi Christian
>
> Just one comments for the meeting in IRC.
> It is not an Apache Way to make decision through the IRC.
> As you know the time you chose is the middle night (3 AM) in my timezone.
>
> Maybe we can drop a discussion lines in the wiki page, so every one who
> wants to join the discussion can have the same page to look in. It could be
> helpful to past the IRC talk into the wiki page at the same time.
>
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://www.fusesource.com | http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
> (English)
> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
>
>
> On Tuesday, January 22, 2013 at 5:34 AM, Christian Müller wrote:
>
> > Hi Hadrian!
> >
> > Please find my comments inline.
> >
> > Best,
> > Christian
> >
> > On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbarcea@gmail.com(mailto:
> hzbarcea@gmail.com)> wrote:
> >
> > > Christian,
> > >
> > > Thanks for taking the initiative and restarting the process for Camel
> 3.0.
> > > The good news imho is that we're under no pressure and we can take the
> time
> > > to get it right.
> >
> >
> > Right.
> >
> > >
> > > I like your proposal of effectively splitting the camel-3.0-roadmap
> page
> > > into multiple pages. If I understand correctly you are suggesting the
> > > following:
> > > - proposals should go on the [ideas] wiki and the discussions on the
> > > mailing lists would refer to the wiki
> > > - the [ideas] page should only contain items currently under discussion
> > > - accepted ideas should move to one of the [roadmap] pages
> > > - keep separate [roadmap] pages for changes to be implemented in
> > > [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
> >
> >
> > Absolute correct.
> >
> > >
> > > The goal is to move faster and to avoid votes except in highly
> contentious
> > > situations which we hope to avoid. I think that would work. I also
> think
> > > that have an open concall on irc (plus maybe other channel) at a
> scheduled
> > > time would be great, although hard to accommodate the time zones.
> >
> >
> > Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
> > I'm open for others if someone has issues with this (starting tomorrow).
> I
> > propose we use our normal IRC chat room at irc://irc.codehaus.org/camel(
> http://irc.codehaus.org/camel) and
> > see how it works. Using IRC has the advantage of easy publishing the chat
> > at dev@ after.
> >
> > >
> > > I would add the following:
> > > 1. The ideas on the [ideas] page should be short, containing just an
> > > abstract. If it takes more than that the details should go in a
> separate
> > > [discuss] thread or another page.
> >
> >
> > Do you think we should go ahead and endorse on the ideas page? Otherwise
> I
> > will start some [DISCUSS] threads for the ideas I will promote.
> >
> >
> > > 2. Keep [discuss] threads focused on one topic only
> > > 3. Use endorsements (e.g. username or initials like [hadrian]) to show
> > > support for an idea (or [-1 hadrian] for a negative endorsement)
> >
> >
> > Good idea. I updated the new Roadmap page.
> >
> > > 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
> > > something) and no negative endorsement for at least say 72 hours or
> more,
> > > we move it to a [roadmap] page.
> > > 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
> > > 6. I am also thinking that each accepted idea on the [roadmap] should
> have
> > > a champion (not necessarily to implement/commit the code, but stay on
> top
> > > of it)
> > >
> > > If no objections within 3 hours I will get to organizing the pages.
> > Thanks for the initial work.
> >
> > >
> > > In terms of concrete development, Guillaume had a very interesting
> > > proposal at ACEU in November. We discussed concrete ways of
> refactoring the
> > > api and realized that it's very hard to fully explain an idea without
> > > showing some code and it's even harder to grasp the consequences
> without
> > > experimenting a bit with the code. We talked about doing that either
> in a
> > > (1) separate, possibly github, repo, (2) on a branch or (3) in the
> sandbox.
> > > This would have the advantage of being able to show an fast idea
> without
> > > concern for backward compatibility and all. More I thought about it,
> more I
> > > liked the approach. Of the three alternatives, the one I like the most
> is
> > > (3), I guess.
> >
> >
> > If we can have multiple sandboxes for different ideas, +1.
> >
> > To anticipate objections (miscommunication will happen no matter how hard
> > > we'll try) backward compatibility and easy, painless migration are
> major
> > > goals for 3.0, I would assume everybody agrees. The ways to get there
> are
> > > many though.
> > >
> > > Thoughts?
> > > Hadrian
> > >
> > >
> > >
> > > On 01/16/2013 04:12 PM, Christian Müller wrote:
> > >
> > > > I find it very difficult to start a such huge and important
> challenge as
> > > > Camel 3.0 will be, for sure. I think the most difficult part is to
> get
> > > > consensus about what we do it and how we do it. We already collect
> some
> > > > useful ideas at [1], but I have the feeling we have to review these
> ideas.
> > > > First of all, because I don't think we can do all of them in one
> release
> > > > (I
> > > > also have a few more - more important from my point of view - ideas,
> > > > collected from users, contributors, committers and PMC members).
> Second,
> > > > some ideas need more "meat" before someone else than the authors
> know what
> > > > this means and which impact it has. Third, a few of these ideas are
> > > > already
> > > > implemented in Camel 2.11 or before, so that we can remove it from
> this
> > > > page to be more focused.
> > > >
> > > > - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
> > > >
> > > > - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill
> with
> > > > content in the next weeks
> > > > - I propose to subdivide this page into three (child) pages:
> > > > - What has to be done before we can start working on Camel 3.0
> > > > (probably
> > > > during the (short term) Camel 2.12)
> > > > - What are the changes we do in Camel 3.0
> > > > - What is postpone to 3.1 or later
> > > > - Afterwards we put everything together, we will see on which ideas
> we
> > > > already agree and which ones requires detailed discussions.
> > > > - For later ones I propose a weekly (or two times per week) IRC/Skype
> > > > session for discussion (Which days/time fit best for you?)
> > > > - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at
> dev@for
> > > > the guys they are not able to attend
> > > > - Afterwards we will send the results to the dev@ mailing list to
> > > > share
> > > > it (if you are interested in it, join us at dev@camel.apache.org(mailto:
> dev@camel.apache.org))
> > > >
> > > > I will start with it after 72 h to give everyone the possibility to
> > > > suggest
> > > > another approach (I will only start writing down some ideas which
> are not
> > > > on table right now). And of course, every help is welcome. A simple
> -1 or
> > > > better +1 ;-) is not much, but also helpful and better than no
> feedback...
> > > > Better, if you join us [2] and ride together with us Camel 3.0.
> > > >
> > > > [1] http://camel.apache.org/camel-**30-roadmap.html<
> http://camel.apache.org/camel-30-roadmap.html>
> > > > [2] http://camel.apache.org/**contributing.html<
> http://camel.apache.org/contributing.html>
> > > >
> > > > Best,
> > > > Christian
> > > >
> > > > --
> >
> >
> > --
>
>
>
--
Re: [CAMEL-3.0] Start moving forward
Posted by Willem jiang <wi...@gmail.com>.
Hi Christian
Just one comments for the meeting in IRC.
It is not an Apache Way to make decision through the IRC.
As you know the time you chose is the middle night (3 AM) in my timezone.
Maybe we can drop a discussion lines in the wiki page, so every one who wants to join the discussion can have the same page to look in. It could be helpful to past the IRC talk into the wiki page at the same time.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, January 22, 2013 at 5:34 AM, Christian Müller wrote:
> Hi Hadrian!
>
> Please find my comments inline.
>
> Best,
> Christian
>
> On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbarcea@gmail.com (mailto:hzbarcea@gmail.com)> wrote:
>
> > Christian,
> >
> > Thanks for taking the initiative and restarting the process for Camel 3.0.
> > The good news imho is that we're under no pressure and we can take the time
> > to get it right.
>
>
> Right.
>
> >
> > I like your proposal of effectively splitting the camel-3.0-roadmap page
> > into multiple pages. If I understand correctly you are suggesting the
> > following:
> > - proposals should go on the [ideas] wiki and the discussions on the
> > mailing lists would refer to the wiki
> > - the [ideas] page should only contain items currently under discussion
> > - accepted ideas should move to one of the [roadmap] pages
> > - keep separate [roadmap] pages for changes to be implemented in
> > [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
>
>
> Absolute correct.
>
> >
> > The goal is to move faster and to avoid votes except in highly contentious
> > situations which we hope to avoid. I think that would work. I also think
> > that have an open concall on irc (plus maybe other channel) at a scheduled
> > time would be great, although hard to accommodate the time zones.
>
>
> Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
> I'm open for others if someone has issues with this (starting tomorrow). I
> propose we use our normal IRC chat room at irc://irc.codehaus.org/camel (http://irc.codehaus.org/camel) and
> see how it works. Using IRC has the advantage of easy publishing the chat
> at dev@ after.
>
> >
> > I would add the following:
> > 1. The ideas on the [ideas] page should be short, containing just an
> > abstract. If it takes more than that the details should go in a separate
> > [discuss] thread or another page.
>
>
> Do you think we should go ahead and endorse on the ideas page? Otherwise I
> will start some [DISCUSS] threads for the ideas I will promote.
>
>
> > 2. Keep [discuss] threads focused on one topic only
> > 3. Use endorsements (e.g. username or initials like [hadrian]) to show
> > support for an idea (or [-1 hadrian] for a negative endorsement)
>
>
> Good idea. I updated the new Roadmap page.
>
> > 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
> > something) and no negative endorsement for at least say 72 hours or more,
> > we move it to a [roadmap] page.
> > 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
> > 6. I am also thinking that each accepted idea on the [roadmap] should have
> > a champion (not necessarily to implement/commit the code, but stay on top
> > of it)
> >
> > If no objections within 3 hours I will get to organizing the pages.
> Thanks for the initial work.
>
> >
> > In terms of concrete development, Guillaume had a very interesting
> > proposal at ACEU in November. We discussed concrete ways of refactoring the
> > api and realized that it's very hard to fully explain an idea without
> > showing some code and it's even harder to grasp the consequences without
> > experimenting a bit with the code. We talked about doing that either in a
> > (1) separate, possibly github, repo, (2) on a branch or (3) in the sandbox.
> > This would have the advantage of being able to show an fast idea without
> > concern for backward compatibility and all. More I thought about it, more I
> > liked the approach. Of the three alternatives, the one I like the most is
> > (3), I guess.
>
>
> If we can have multiple sandboxes for different ideas, +1.
>
> To anticipate objections (miscommunication will happen no matter how hard
> > we'll try) backward compatibility and easy, painless migration are major
> > goals for 3.0, I would assume everybody agrees. The ways to get there are
> > many though.
> >
> > Thoughts?
> > Hadrian
> >
> >
> >
> > On 01/16/2013 04:12 PM, Christian Müller wrote:
> >
> > > I find it very difficult to start a such huge and important challenge as
> > > Camel 3.0 will be, for sure. I think the most difficult part is to get
> > > consensus about what we do it and how we do it. We already collect some
> > > useful ideas at [1], but I have the feeling we have to review these ideas.
> > > First of all, because I don't think we can do all of them in one release
> > > (I
> > > also have a few more - more important from my point of view - ideas,
> > > collected from users, contributors, committers and PMC members). Second,
> > > some ideas need more "meat" before someone else than the authors know what
> > > this means and which impact it has. Third, a few of these ideas are
> > > already
> > > implemented in Camel 2.11 or before, so that we can remove it from this
> > > page to be more focused.
> > >
> > > - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
> > >
> > > - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> > > content in the next weeks
> > > - I propose to subdivide this page into three (child) pages:
> > > - What has to be done before we can start working on Camel 3.0
> > > (probably
> > > during the (short term) Camel 2.12)
> > > - What are the changes we do in Camel 3.0
> > > - What is postpone to 3.1 or later
> > > - Afterwards we put everything together, we will see on which ideas we
> > > already agree and which ones requires detailed discussions.
> > > - For later ones I propose a weekly (or two times per week) IRC/Skype
> > > session for discussion (Which days/time fit best for you?)
> > > - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@for
> > > the guys they are not able to attend
> > > - Afterwards we will send the results to the dev@ mailing list to
> > > share
> > > it (if you are interested in it, join us at dev@camel.apache.org (mailto:dev@camel.apache.org))
> > >
> > > I will start with it after 72 h to give everyone the possibility to
> > > suggest
> > > another approach (I will only start writing down some ideas which are not
> > > on table right now). And of course, every help is welcome. A simple -1 or
> > > better +1 ;-) is not much, but also helpful and better than no feedback...
> > > Better, if you join us [2] and ride together with us Camel 3.0.
> > >
> > > [1] http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>
> > > [2] http://camel.apache.org/**contributing.html<http://camel.apache.org/contributing.html>
> > >
> > > Best,
> > > Christian
> > >
> > > --
>
>
> --
Re: [CAMEL-3.0] Start moving forward
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Looks like we're starting to get more feedback. Awesome. More inline...
Also moved back from users@ to dev@. I really don't think this should be
on dev. If we want to make users aware of this discussions, I'd do that
via announcements on the site and maybe occasional posts to users@, but
I think now it's premature.
Hadrian
On 01/21/2013 04:34 PM, Christian Müller wrote:
> Hi Hadrian!
>
> Please find my comments inline.
>
> Best,
> Christian
>
> On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
>> Christian,
>>
>> Thanks for taking the initiative and restarting the process for Camel 3.0.
>> The good news imho is that we're under no pressure and we can take the time
>> to get it right.
>>
> Right.
>
>>
>> I like your proposal of effectively splitting the camel-3.0-roadmap page
>> into multiple pages. If I understand correctly you are suggesting the
>> following:
>> - proposals should go on the [ideas] wiki and the discussions on the
>> mailing lists would refer to the wiki
>> - the [ideas] page should only contain items currently under discussion
>> - accepted ideas should move to one of the [roadmap] pages
>> - keep separate [roadmap] pages for changes to be implemented in
>> [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
>>
> Absolute correct.
>
>>
>> The goal is to move faster and to avoid votes except in highly contentious
>> situations which we hope to avoid. I think that would work. I also think
>> that have an open concall on irc (plus maybe other channel) at a scheduled
>> time would be great, although hard to accommodate the time zones.
>>
> Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
> I'm open for others if someone has issues with this (starting tomorrow). I
> propose we use our normal IRC chat room at irc://irc.codehaus.org/camel and
> see how it works. Using IRC has the advantage of easy publishing the chat
> at dev@ after.
That's 1-2pm EST. Works for me.
>
>>
>> I would add the following:
>> 1. The ideas on the [ideas] page should be short, containing just an
>> abstract. If it takes more than that the details should go in a separate
>> [discuss] thread or another page.
>>
> Do you think we should go ahead and endorse on the ideas page? Otherwise I
> will start some [DISCUSS] threads for the ideas I will promote.
The ideas page is public. The discussions on dev@ are public. My
personal take is that if it was endorsed by a quorum of committers (say
at least 3) for a number of days (at least 3), it may be safe to
consider lazy consensus and move it to the roadmap. It would be childish
to start to [discuss] things we consider more or less obvious. If
anybody changes his mind later on, we can always revisit a decision,
which is what we were doing all along anyway.
>> 2. Keep [discuss] threads focused on one topic only
>> 3. Use endorsements (e.g. username or initials like [hadrian]) to show
>> support for an idea (or [-1 hadrian] for a negative endorsement)
>>
> Good idea. I updated the new Roadmap page.
>
>> 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
>> something) and no negative endorsement for at least say 72 hours or more,
>> we move it to a [roadmap] page.
>> 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
>> 6. I am also thinking that each accepted idea on the [roadmap] should have
>> a champion (not necessarily to implement/commit the code, but stay on top
>> of it)
>>
>> If no objections within 3 hours I will get to organizing the pages.
>>
> Thanks for the initial work.
>
>>
>> In terms of concrete development, Guillaume had a very interesting
>> proposal at ACEU in November. We discussed concrete ways of refactoring the
>> api and realized that it's very hard to fully explain an idea without
>> showing some code and it's even harder to grasp the consequences without
>> experimenting a bit with the code. We talked about doing that either in a
>> (1) separate, possibly github, repo, (2) on a branch or (3) in the sandbox.
>> This would have the advantage of being able to show an fast idea without
>> concern for backward compatibility and all. More I thought about it, more I
>> liked the approach. Of the three alternatives, the one I like the most is
>> (3), I guess.
>>
> If we can have multiple sandboxes for different ideas, +1.
If needed, yeah.
>
> To anticipate objections (miscommunication will happen no matter how hard
>> we'll try) backward compatibility and easy, painless migration are major
>> goals for 3.0, I would assume everybody agrees. The ways to get there are
>> many though.
>>
>> Thoughts?
>> Hadrian
>>
>>
>>
>> On 01/16/2013 04:12 PM, Christian Müller wrote:
>>
>>> I find it very difficult to start a such huge and important challenge as
>>> Camel 3.0 will be, for sure. I think the most difficult part is to get
>>> consensus about what we do it and how we do it. We already collect some
>>> useful ideas at [1], but I have the feeling we have to review these ideas.
>>> First of all, because I don't think we can do all of them in one release
>>> (I
>>> also have a few more - more important from my point of view - ideas,
>>> collected from users, contributors, committers and PMC members). Second,
>>> some ideas need more "meat" before someone else than the authors know what
>>> this means and which impact it has. Third, a few of these ideas are
>>> already
>>> implemented in Camel 2.11 or before, so that we can remove it from this
>>> page to be more focused.
>>>
>>> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>>>
>>> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
>>> content in the next weeks
>>> - I propose to subdivide this page into three (child) pages:
>>> - What has to be done before we can start working on Camel 3.0
>>> (probably
>>> during the (short term) Camel 2.12)
>>> - What are the changes we do in Camel 3.0
>>> - What is postpone to 3.1 or later
>>> - Afterwards we put everything together, we will see on which ideas we
>>> already agree and which ones requires detailed discussions.
>>> - For later ones I propose a weekly (or two times per week) IRC/Skype
>>> session for discussion (Which days/time fit best for you?)
>>> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@for
>>> the guys they are not able to attend
>>> - Afterwards we will send the results to the dev@ mailing list to
>>> share
>>> it (if you are interested in it, join us at dev@camel.apache.org)
>>>
>>> I will start with it after 72 h to give everyone the possibility to
>>> suggest
>>> another approach (I will only start writing down some ideas which are not
>>> on table right now). And of course, every help is welcome. A simple -1 or
>>> better +1 ;-) is not much, but also helpful and better than no feedback...
>>> Better, if you join us [2] and ride together with us Camel 3.0.
>>>
>>> [1] http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>
>>> [2] http://camel.apache.org/**contributing.html<http://camel.apache.org/contributing.html>
>>>
>>> Best,
>>> Christian
>>>
>>> --
>>>
>>>
>
>
> --
>
Re: [CAMEL-3.0] Start moving forward
Posted by Christian Müller <ch...@gmail.com>.
Hi Hadrian!
Please find my comments inline.
Best,
Christian
On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Christian,
>
> Thanks for taking the initiative and restarting the process for Camel 3.0.
> The good news imho is that we're under no pressure and we can take the time
> to get it right.
>
Right.
>
> I like your proposal of effectively splitting the camel-3.0-roadmap page
> into multiple pages. If I understand correctly you are suggesting the
> following:
> - proposals should go on the [ideas] wiki and the discussions on the
> mailing lists would refer to the wiki
> - the [ideas] page should only contain items currently under discussion
> - accepted ideas should move to one of the [roadmap] pages
> - keep separate [roadmap] pages for changes to be implemented in
> [2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
>
Absolute correct.
>
> The goal is to move faster and to avoid votes except in highly contentious
> situations which we hope to avoid. I think that would work. I also think
> that have an open concall on irc (plus maybe other channel) at a scheduled
> time would be great, although hard to accommodate the time zones.
>
Right. I propose every Tuesday 7:00 - 8:00 PM Central European Time, but
I'm open for others if someone has issues with this (starting tomorrow). I
propose we use our normal IRC chat room at irc://irc.codehaus.org/camel and
see how it works. Using IRC has the advantage of easy publishing the chat
at dev@ after.
>
> I would add the following:
> 1. The ideas on the [ideas] page should be short, containing just an
> abstract. If it takes more than that the details should go in a separate
> [discuss] thread or another page.
>
Do you think we should go ahead and endorse on the ideas page? Otherwise I
will start some [DISCUSS] threads for the ideas I will promote.
> 2. Keep [discuss] threads focused on one topic only
> 3. Use endorsements (e.g. username or initials like [hadrian]) to show
> support for an idea (or [-1 hadrian] for a negative endorsement)
>
Good idea. I updated the new Roadmap page.
> 4. Once an idea has enough endorsements (3-5, dunno, need to agree on
> something) and no negative endorsement for at least say 72 hours or more,
> we move it to a [roadmap] page.
> 5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
> 6. I am also thinking that each accepted idea on the [roadmap] should have
> a champion (not necessarily to implement/commit the code, but stay on top
> of it)
>
> If no objections within 3 hours I will get to organizing the pages.
>
Thanks for the initial work.
>
> In terms of concrete development, Guillaume had a very interesting
> proposal at ACEU in November. We discussed concrete ways of refactoring the
> api and realized that it's very hard to fully explain an idea without
> showing some code and it's even harder to grasp the consequences without
> experimenting a bit with the code. We talked about doing that either in a
> (1) separate, possibly github, repo, (2) on a branch or (3) in the sandbox.
> This would have the advantage of being able to show an fast idea without
> concern for backward compatibility and all. More I thought about it, more I
> liked the approach. Of the three alternatives, the one I like the most is
> (3), I guess.
>
If we can have multiple sandboxes for different ideas, +1.
To anticipate objections (miscommunication will happen no matter how hard
> we'll try) backward compatibility and easy, painless migration are major
> goals for 3.0, I would assume everybody agrees. The ways to get there are
> many though.
>
> Thoughts?
> Hadrian
>
>
>
> On 01/16/2013 04:12 PM, Christian Müller wrote:
>
>> I find it very difficult to start a such huge and important challenge as
>> Camel 3.0 will be, for sure. I think the most difficult part is to get
>> consensus about what we do it and how we do it. We already collect some
>> useful ideas at [1], but I have the feeling we have to review these ideas.
>> First of all, because I don't think we can do all of them in one release
>> (I
>> also have a few more - more important from my point of view - ideas,
>> collected from users, contributors, committers and PMC members). Second,
>> some ideas need more "meat" before someone else than the authors know what
>> this means and which impact it has. Third, a few of these ideas are
>> already
>> implemented in Camel 2.11 or before, so that we can remove it from this
>> page to be more focused.
>>
>> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>>
>> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
>> content in the next weeks
>> - I propose to subdivide this page into three (child) pages:
>> - What has to be done before we can start working on Camel 3.0
>> (probably
>> during the (short term) Camel 2.12)
>> - What are the changes we do in Camel 3.0
>> - What is postpone to 3.1 or later
>> - Afterwards we put everything together, we will see on which ideas we
>> already agree and which ones requires detailed discussions.
>> - For later ones I propose a weekly (or two times per week) IRC/Skype
>> session for discussion (Which days/time fit best for you?)
>> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@for
>> the guys they are not able to attend
>> - Afterwards we will send the results to the dev@ mailing list to
>> share
>> it (if you are interested in it, join us at dev@camel.apache.org)
>>
>> I will start with it after 72 h to give everyone the possibility to
>> suggest
>> another approach (I will only start writing down some ideas which are not
>> on table right now). And of course, every help is welcome. A simple -1 or
>> better +1 ;-) is not much, but also helpful and better than no feedback...
>> Better, if you join us [2] and ride together with us Camel 3.0.
>>
>> [1] http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>
>> [2] http://camel.apache.org/**contributing.html<http://camel.apache.org/contributing.html>
>>
>> Best,
>> Christian
>>
>> --
>>
>>
--
Re: [CAMEL-3.0] Start moving forward
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Christian,
Thanks for taking the initiative and restarting the process for Camel
3.0. The good news imho is that we're under no pressure and we can take
the time to get it right.
I like your proposal of effectively splitting the camel-3.0-roadmap page
into multiple pages. If I understand correctly you are suggesting the
following:
- proposals should go on the [ideas] wiki and the discussions on the
mailing lists would refer to the wiki
- the [ideas] page should only contain items currently under discussion
- accepted ideas should move to one of the [roadmap] pages
- keep separate [roadmap] pages for changes to be implemented in
[2.x-roadmap], [3.0-roadmap] and [3.x-roadmap]
The goal is to move faster and to avoid votes except in highly
contentious situations which we hope to avoid. I think that would work.
I also think that have an open concall on irc (plus maybe other channel)
at a scheduled time would be great, although hard to accommodate the
time zones.
I would add the following:
1. The ideas on the [ideas] page should be short, containing just an
abstract. If it takes more than that the details should go in a separate
[discuss] thread or another page.
2. Keep [discuss] threads focused on one topic only
3. Use endorsements (e.g. username or initials like [hadrian]) to show
support for an idea (or [-1 hadrian] for a negative endorsement)
4. Once an idea has enough endorsements (3-5, dunno, need to agree on
something) and no negative endorsement for at least say 72 hours or
more, we move it to a [roadmap] page.
5. Have only a limited number of 'editors' to move [ideas] to [roadmap]
6. I am also thinking that each accepted idea on the [roadmap] should
have a champion (not necessarily to implement/commit the code, but stay
on top of it)
If no objections within 3 hours I will get to organizing the pages.
In terms of concrete development, Guillaume had a very interesting
proposal at ACEU in November. We discussed concrete ways of refactoring
the api and realized that it's very hard to fully explain an idea
without showing some code and it's even harder to grasp the consequences
without experimenting a bit with the code. We talked about doing that
either in a (1) separate, possibly github, repo, (2) on a branch or (3)
in the sandbox. This would have the advantage of being able to show an
fast idea without concern for backward compatibility and all. More I
thought about it, more I liked the approach. Of the three alternatives,
the one I like the most is (3), I guess.
To anticipate objections (miscommunication will happen no matter how
hard we'll try) backward compatibility and easy, painless migration are
major goals for 3.0, I would assume everybody agrees. The ways to get
there are many though.
Thoughts?
Hadrian
On 01/16/2013 04:12 PM, Christian Müller wrote:
> I find it very difficult to start a such huge and important challenge as
> Camel 3.0 will be, for sure. I think the most difficult part is to get
> consensus about what we do it and how we do it. We already collect some
> useful ideas at [1], but I have the feeling we have to review these ideas.
> First of all, because I don't think we can do all of them in one release (I
> also have a few more - more important from my point of view - ideas,
> collected from users, contributors, committers and PMC members). Second,
> some ideas need more "meat" before someone else than the authors know what
> this means and which impact it has. Third, a few of these ideas are already
> implemented in Camel 2.11 or before, so that we can remove it from this
> page to be more focused.
>
> - Rename "Camel 3.0 - Roadmap" into "Camel 3.0 - Ideas"
>
> - Start a fresh "Camel 3.0 - Roadmap" WIKI page which we will fill with
> content in the next weeks
> - I propose to subdivide this page into three (child) pages:
> - What has to be done before we can start working on Camel 3.0 (probably
> during the (short term) Camel 2.12)
> - What are the changes we do in Camel 3.0
> - What is postpone to 3.1 or later
> - Afterwards we put everything together, we will see on which ideas we
> already agree and which ones requires detailed discussions.
> - For later ones I propose a weekly (or two times per week) IRC/Skype
> session for discussion (Which days/time fit best for you?)
> - We should also start a [DISCUSS CAMEL-3.0: <TOPIC>] thread at dev@ for
> the guys they are not able to attend
> - Afterwards we will send the results to the dev@ mailing list to share
> it (if you are interested in it, join us at dev@camel.apache.org)
>
> I will start with it after 72 h to give everyone the possibility to suggest
> another approach (I will only start writing down some ideas which are not
> on table right now). And of course, every help is welcome. A simple -1 or
> better +1 ;-) is not much, but also helpful and better than no feedback...
> Better, if you join us [2] and ride together with us Camel 3.0.
>
> [1] http://camel.apache.org/camel-30-roadmap.html
> [2] http://camel.apache.org/contributing.html
>
> Best,
> Christian
>
> --
>