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 <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 > > > > > > > > > > -- > > > > > > > > > --
