[CAMEL-3.0] Start moving forward

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[CAMEL-3.0] Start moving forward

Christian Mueller
Administrator
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 [hidden email])

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

--
Reply | Threaded
Open this post in threaded view
|

Re: [CAMEL-3.0] Start moving forward

Willem.Jiang
Administrator
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 [hidden email] (mailto:[hidden email]))
>  
> 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
>  
> --  


Reply | Threaded
Open this post in threaded view
|

Re: [CAMEL-3.0] Start moving forward

hadrian
In reply to this post by Christian Mueller
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 [hidden email])
>
> 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
>
> --
>
Reply | Threaded
Open this post in threaded view
|

Re: [CAMEL-3.0] Start moving forward

Christian Mueller
Administrator
Hi Hadrian!

Please find my comments inline.

Best,
Christian

On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <[hidden email]> 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 [hidden email])
>>
>> 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
>>
>> --
>>
>>


--