> Leonardo Uribe wrote: >> >> >> On Mon, Mar 3, 2008 at 4:58 PM, simon <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> The list of components is fine. And I very much appreciate all >> your work >> on this and the tomahawk bugs you've been fixing recently. >> >> However at the risk of sounding like a broken record, I would >> like to >> point out that AFAIK there has still been no vote on whether to >> have a >> tomahawk 2.0 at all. And I would vote -1 on such a thing; abandoning >> tomahawk users on JSF1.1 would be bad, and the community is just >> not big >> enough to support two parallel tomahawk branches. The fact that >> you are >> about the only person to commit to tomahawk in the last month should >> make that obvious. The minor benefits of a JSF1.2-specific tomahawk >> branch are far outweighed by the pain. >> >> >> I have a different opinion about this. Sooner or later we have to >> upgrade this lib (I think better sooner than later). >> The component generator does the big part of the update (write >> component and tag classes), >> only minor changes on the renderers was done to make all examples >> work (the big part >> of the work is on build module). Move changes from one branch to >> another should be an >> easy task. Passing tomahawk to 1.2 let us see more bug on myfaces >> 1.2, and upgrade >> tomahawk 1.1 apps should be easy. JSF 1.2 has more than one year and >> JSF 2.0 is >> coming. The only thing to be taken into account is continue doing >> releases on >> 1.1 and that's all. >> >> It's a matter of subjective opinions (all valid of course). But in my >> humble opinion, better >> move forward than stay quiet. Not one step back, nor to catch momentum. >> >> regards >> >> Leonardo Uribe > Scott O'Bryan schrieb: > I agree with Leonardo totally. Just because you have a 2.0 branch > does not mean that you drop support for 1.1. It simply means that > things which cannot be made 1.1 compatible continue to migrate and > that the stuff which is already in place, embraces any emerging > standards. Furthermore, it gives Tomahawk users a much clearer > upgrade path into the new technologies. Trinidad, for instance, has > had a 1.2 branch for a few months and we are totally seeing > enhancements going into both branches. Things go into 1.2 as the > exception, not the rule. > > I fully support making sure that 1.1 continues to move ahead because > 1.1 is MyFace's largest community of users. But PREVENTING projects > from moving to the new technology only hurts those renderkits and > helps no-one.... One of the key issues with open source is that > developers work on what they want/need to work on. If people in the > community continue to restrict developers from supporting the new > standards for a renderkit, the renderkit will loose developers and > support. Instead of having active development in a project with a > little more emphasis on the later standards, you'll end up with no > development at all.
Argh..top-posting in reply to a thread that already has bottom-posting established as a convention is REALLY ANNOYING. I've therefore moved the reply text to a sane position. The thing I am really concerned about here is ensuring that there are enough tomahawk developers to actually keep the project alive. Therefore in this case, I think that only the opinions of those who are actually active developers count. Scott, it's all very well you saying that both 1.1 and 1.2 should be supported, but someone has to actually do that, and I don't see your name in the commit list... Here's some actual stats on commits since feb 2007 (ie for the last 12 months) baranda: 3 bommel: 1 (website only) cagatay: 14 dennisbyrne: 2 gmuellan: 6 grantsmith: 13 imario: 10 jlust: 1 manolito: 10 (mostly buildsystem fixes) matzew: 4 mkienenb: 14 mmarinschek: 8 pmahoney: 24 skitching: 42 tomsp: 2 werpu: 4 total patches: 158 in 12 months --> 13 per month -> 3 per week Hmm..interestingly, lu4242 (Leonardo) does not appear on this list, except for one of matzew's patches that credits leonardo. All Leonardo's patches must have been to sandbox or the "tomahawk 2.0 branch". I think we can count Leonardo among the active developer pool anyway. By the way, a lot of the above commits are checking in patches provided by other people; sorry I can't properly credit them here. The numbers for myself (skitching) are somewhat misleading; a big chunk of those are just on one component, the t:calendar. And likewise for pmahoney; most of the commits are just for the schedule component. This really does not look like a lot of people or traffic. Now let's look at JIRA: http://issues.apache.org/jira/browse/TOMAHAWK There are 390 open issues of severity Major or above. So at the current commit rate, that will take 2.5 years to clear them, assuming one patch fixes one issue. In this situation, we really do NOT need to increase the amount of work it takes to maintain Tomahawk. Leonardo, are you saying that moving to a code-generation approach will allow us to maintain a single trunk of code that can then be "generated" into JSF1.1 *and* JSF1.2 compatible variants without additional effort? That would be nice, but I do find it hard to believe... And I am still puzzled about what these gains a JSF1.2-specific tomahawk will get. Ok, so we get to use the new for-loops and generic collections. Excuse me for not getting up and dancing around the room; these are nice but not *that* exciting. JSF1.2 *is* generally backwards-compatible, so by sticking with JSF1.1 we support *both* sets of users with just one trunk of code. On the issue of using the maven-faces-plugin code generator, I'm a little less concerned; -0 would be my vote. I believe it will raise the complexity bar for external patch contributors and new committers which again is not what we need right now. However it's not fatal. The splitting of code into two trunks means checking each patch against both branches. This duplication of work, unit tests, etc. is the bit I'm really afraid will lead to the JSF1.1 branch of tomahawk dying from neglect very shortly after any "tomahawk 2.0" release. The only people who can stop that are active committers - and at least one (me) is very worried. Regards, Simon
