On Tue, Jan 22, 2013 at 10:25 PM, Christian Müller <christian.muel...@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 <willem.ji...@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 >> > <hzbar...@gmail.com(mailto: >> 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( >> 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: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
