Hi Hadrian! Please find my comments inline.
Best, Christian On Thu, Jan 17, 2013 at 2:47 PM, Hadrian Zbarcea <hzbar...@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 d...@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 >> >> -- >> >> --
