On Fri, Jan 2, 2009 at 8:04 AM, Jeremy Thomerson <[email protected]> wrote: >> this patch messes with url processing which is very fragile in wicket. >> how extensively have you tested this because there are probably ten >> bugs open right now for similar issues. we fix one and another one >> pops up, so we are very careful when it comes to messing with stuff >> like this. are you sure that patch didnt break any of the other >> hundred usecases that have to do with ajax and ie6 on tomcat vs ie7 on >> jetty? i hope juergen tested it extensively before applying. > > > I ran all tests with "mvn clean test" and tested what I could in a > quickstart. What else would you suggest?
this patch has to do with ajax functionality. i would suggest running the attached quickstart on all javascript engines that we support: ie6.0, ie6.5, ie7, safari (whatever two major versions there are out there), firefox 2, firefox 3, opera, blah blah blah blah. than test running it on tomcat 5, tomcat 6, jetty, etc. see why we are careful with stuff like this? there are a lot of variables that contribute to issues like this and our automated tests do not cover all of them. so its not unusual for an issue like this to sit open for a long time, until one of the core devs has an entire day to kill on it. >> > WICKET-1567 >> >> this wasnt applied yet because it has to do with 1.3 and compatibility >> issues. are you sure there are no deployed wicket applications out >> there that will break after this patch is applied because they depend >> on existing behavior? > > > It's a *bug* in 1.3. Since it was fixed in trunk, I assumed that the core > devs had already considered it "safe" for future upgrades. we do not care about breaking backwards compat in trunk nearly as much as in 1.3.x releases. the rules there are different. > No - we're never > sure if there are "any" apps that will break, but this seems very innocuous. > > Besides - what "existing behavior" could they be depending on - it currently > generates an invalid link that doesn't work? we have come across a lot of issues while working on stable branches where we fix something trivial like this - which hardly affects anyone - and break a behavior that someone else has coded against. the severity of this bug is very low and there are easy workarounds, so we have to weight that against a chance of breaking something already deployed. >> > Anyway - since I worked to fix those bugs, I don't want to see them fall >> > through the cracks and would like to see them make it into future >> releases. >> >> sure, but you also have to look at it from out point of view. you >> write the patch which takes x time. we have to maintain that code >> after you are done, which takes x*1000 time. so just because there is >> a patch doesnt mean it will be applied. if you really want to help you >> should concentrate on bugs for trunk. if you want to work on a "wish" >> type issue or a 1.3 bug that changes runtime behavior you should let >> it be known on the dev@ so we can make sure it is something we will >> want to maintian. > > > I guess this is something I don't understand. Since the core devs are > focused on getting another high-quality release out (1.4), it would seem to > me that you would rather welcome true bug fixes for the 1.3 branch, which is > probably (my guess only) the most-deployed version out there. only if you understand the restrictions that apply to making code changes in 1.3 branch. > I understand that not all patches will be committed, but what else can I do > to help besides go through issues filed as bugs, fix them, run all tests and > submit the patch? not get pissed off when your patch is not applied right away or for a while :) > What else do you do personally when you are fixing bugs? when it comes to 1.3 branch i am a lot more conscientious of what code i am changing and how it affects deployed apps. there were more then a few times when i had to rollback the changes i committed when someone pointed out that it breaks compatibility in some way. when dealing with ajax bugs i do a lot more testing then just the automated tests (which is why i usually assign ajax related stuff to matej :) ). -igor > > >> >> >> thanks for your contributions. >> >> -igor >> >> > >> > Thanks! >> > >> > -- >> > Jeremy Thomerson >> > http://www.wickettraining.com >> > >> > > > > -- > Jeremy Thomerson > http://www.wickettraining.com >
