David, I'm really sorry if I came across badly, like if it sounded cynical or something. I did not mean it that way! Everything you wrote about how much toil you put into this project, that's exactly my point! It's your brainchild, you started it, and you keep it going, and that's why I said is that the final decision is up to you. I know we had a couple of disagreements about names, and as I told you then: I will be happy to debate as long as it's up for discussion; but when you make a final decision, that's your right. I'm not being bitter about it! I mean it 100%. When someone announced they were starting a new forum for Lift, I was the one who said, let's see if DPP minds. @Heiko: I didn't mean that it's DPP's in the sense that it's his toy, not yours and everyone else's opinion is irrelevant! I meant exactly what you responded. But it's not random that the decision maker is DPP. It's all thanks to him after all. So I agree wholeheartedly with everything DPP and Heiko replied, and I'm sorry if I implied otherwise. Gratitude is one of the primary distinctions between man and animal.
------------------------------------- David Pollak<[email protected]> wrote: On Mon, Nov 16, 2009 at 11:08 PM, Naftoli Gugenheim <[email protected]>wrote: > I agree. I would to see a 2.0 or 3.0 or something eventually with a lot of > names improved. If you want to improve names, propose it on this list. Kris just opened up a thread on that and you've been silent. Now is the time to improve method names. Now is the time to suggest alternative class names. It's not going to be wholesale breakage, but the really bad stuff can be renamed and the rest can be politely deprecated. > But it's up to DPP because it's his project. > > Please note how I approached this conversation. I didn't say "no." I didn't say, "over my dead body." I gave my perspective on how much Lift has progressed since 1.0... and I think I've got the experience with Lift to be able to say that. I give a lot of deference to Heiko in terms of his OSGi experience. I have my opinion, but I'm listening and being swayed. So, yes, I have made some decisions that have gone counter to others. Yes, I do have the final word. But think about our conversation when you wanted to add XML for configuring menus in SiteMap. Did I say, "no"? I said, "It's not the way I'd do things, but add it and let's see if people adopt it." When Marius abstracted the Servlet stuff out of Lift, he went about it in a way different than I would have, but I think his results are awesome. There are lots of decisions about Lift that are not my personal inclination, but if they hold together then they work. When things don't work or there's a particular corner case (e.g., Alex's changes to the type erasure issue in Req that I have 2+ years of experience with and he has none), I pull out my veto stamp. Maybe it feels like I do this a lot, but I think that's generally because of lot of stuff happens without a lot of disagreement and it's only when I have to disagree with folks who I have a ton of respect for, there's an "energy spike" on the list and that's what people remember. More broadly, Lift mentally hangs together pretty well. Yes, there's room for improvement. Yes, there are folks with more FP experience than I have who can and are lending excellent perspectives to the code base (take a look at Kris's recent additions). But there's general coherence across the framework. Keeping something hanging together well and keeping people who have no reason to participate except that they want to motivated is non-trivial. Pile onto this the fact that most of the committers are probably the smartest guys in their class. They are among the top 1% of coders in whatever company they work for. Each of the committers is remarkable on his/her own. So, we've got a collection of folks who are 3 standard deviations out in their field who are all opinionated and used to being right almost all the time. I have the challenge of keeping this tremendous group of people aligned and motivated. Now, intersect this with the current time-constraints. I have been a nanny-less single parent for nearly the past month. Derek is traveling with his family and Marius and Tim are busy at work. Debby's been occupied with other gigs so I have less process help than I usually do. I have to balance between debates, supporting the increasing number of production sites (and, yes, Naftoli, I have supported your production site... I was sitting in this line: http://www.uplifting.me/the-h1n1-vaccine-line coding fixes for your tickets to receive a "the names you chose, they're not so good" feedback from you), the Scala 2.8 port, and the flood of newbies on the list. So, yeah, I don't spend 2+ hours a day debating... I make shorter fuse decisions. But, the "it's DPP's ball and he'll do with it what he wants" kind of feedback bugs me at a very, very core level. > ------------------------------------- > Jonathan Ferguson<[email protected]> wrote: > > I was thinking about this earlier, if there is to be a 2.0 I would hope > there was a chance to remove deprecated code. > Which particular deprecated code are you thinking. > Also consider making breaking > changes @dpp hasn't been in favour of making to date. > Which changes are you thinking about? > Not to annoy him. As > 1.X to 2.X is a big enough change that people who don't want to move can > stay with a stable 1.X and those of us who are running HEAD/TRUNK whatever > these new fangled git kids call it nowadays can keep racing along. > I'm not sure we have the resources to support a 1.X and a 2.X and a 2.7.x and a 2.8.x branch. If there are any folks who want to step up and maintain a branch (or if there's money to hire someone), it's something worth a discussion, but I don't think there's anyone I know of who could maintain a 1.X branch if we're going to get radical with a 2.X. I think it's one branch. > > Jono. > > 2009/11/17 Heiko Seeberger <[email protected]> > > > 2009/11/17 David Pollak <[email protected]> > > > >> The current Lift is not a major change to Lift 1.0, it's a minor > >> progression and a lot of tuning of the developer experience. > >> > > > > There are breaking changes to the API which in the version policy > suggested > > by me (the OSGi way) means increasing the major version number. OK, of > > course we need not stick to this particular version policy, but it would > be > > beneficial to have one. What about: Increasing the minor version number > > (e.g. 1.0 -> 1.1) means breaking changes to the API. Increasing the micro > > version number (e.g. 1.1.0 -> 1.1.1) means *no* breaking changes to the > API. > > > > Heiko > > > > > > My job: weiglewilczek.com > > My blog: heikoseeberger.name > > Follow me: twitter.com/hseeberger > > OSGi on Scala: scalamodules.org > > Lift, the simply functional web framework: liftweb.net > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<liftweb%[email protected]> > <liftweb%[email protected]<liftweb%[email protected]> > > > > . > > For more options, visit this group at > > http://groups.google.com/group/liftweb?hl=. > > > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=. > > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
