great! so if there are no negative sentiments showing up anymore, Sylvain and I will start the implementation - there will always be the chance to improve if there are problems for anyone.
regards, Martin On 5/11/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > I agree with Kalle's sentiments that this is the nature of open source > software. Actually not just open source software, but any > collaborative effort. Building a consensus takes time but in the end, > the thorough discussion benefits everyone. While the feature is > relatively simple and our spare time is precious, this is something > that affects all of us. Not every new feature or component will fall > into this category. Tree2 took a lot longer with all of the debate, > but in the end it was better because I got some good ideas from > people. > > In this case I think a vote is appropriate because there are some > strong reservations by some individuals and so Sylvain should have an > unambiguous answer as to how to proceed. We should also be willing to > change code after the fact if it results in an improvement. > > So I say lets go ahead with Sylvain's approach now and lets take a > look at what he comes up with. If we come up with a better solution > or an improvement to the existing solution lets not limit ourselves > with concerns of backwards compatability. > > So I will vote +1 for Sylvain's solution and reserve the right to > reopen the discussion later if we feel there are improvements to be > made. > > sean > > > On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > Sean & Kalle, > > > > I agree that this discussion helped to clarify some things, but I'm a quite > > worried by the time and efforts it takes to agree on such a small feature. > > I don't underestimate the necessity of having a well thought API, but as > > all of you, my time is spare, and I disagree that there is no harm in a > > prolonged discussion. > > If it's just too much effort to decide such issues, I should better do a > > hack on my own, and forget about including it in Myfaces. > > > > Please don't take this as an offense, it's just a general worry that this > > would afraid others like me of contributing anything else than bug fixes. > > I also dislike this voting process, but it is an attempt to keep this in a > > reasonable time frame, so please try to make your mind, but don't ask for > > another week of emails & extensive explanations. > > > > As for the summary of the options, I agree with the one Martin just did > > (thanks for your help by the way). > > > > Sylvain. > > > > > > On Tue, 2005-05-10 at 15:26 -0400, Sean Schofield wrote: > > > While discussing this has taken a long time, I don't see any wrong in > > > it. It's still cheap and easy compared to implementing different > > > components, then comparing their implementations, fixing possible bugs > > > etc. > > > > I agree with Kalle that there is no harm in a prolonged discussion on > > this. If memory serves me, we have only been discussing this for a > > week or so. I think we should consider postponing the vote and taking > > a little more time with this. > > > > My reasoning is that this solves a problem that many of us (including > > myself) need to have solved. Lets pick an approach that we can all > > live with. > > > > On the other hand, we owe it to Sylvain to not drag this out. Lets > > try to resolve this quickly but also give it the consideration it > > deserves. Also, the answer to this problem involves several "design > > principles" that we should probably agree upon. For instance, concern > > over bloated attributes, mutating components, etc. > > > > I need some time to re-read this very extensive thread. Maybe Sylvain > > or Kalle can summarize the options for us (Option #1, #2, etc.) > > People can add new options (give them a new number) and we can have a > > quick discussion and reference these options by # and discuss pros and > > cons. > > > > > Kalle > > > > sean > > > > >
