camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <>
Subject Re: [CAMEL-3.0] Start moving forward
Date Mon, 21 Jan 2013 21:34:02 GMT
Hi Hadrian!

Please find my comments inline.


On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <> 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.

> 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:// 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
>> 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]**30-roadmap.html<>
>> [2]**contributing.html<>
>> Best,
>> Christian
>> --


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message