Quick Jira search reveals bugs I care about: Basically, this is a result of a search of issues that are reported by me, voted on my me or watched by me:
https://issues.apache.org/jira/browse/TAP5-2208 https://issues.apache.org/jira/browse/TAP5-2197 https://issues.apache.org/jira/browse/TAP5-2196 https://issues.apache.org/jira/browse/TAP5-2188 https://issues.apache.org/jira/browse/TAP5-2187 https://issues.apache.org/jira/browse/TAP5-2185 https://issues.apache.org/jira/browse/TAP5-2182 https://issues.apache.org/jira/browse/TAP5-2173 https://issues.apache.org/jira/browse/TAP5-2172 https://issues.apache.org/jira/browse/TAP5-2168 https://issues.apache.org/jira/browse/TAP5-2167 https://issues.apache.org/jira/browse/TAP5-2166 https://issues.apache.org/jira/browse/TAP5-2158 https://issues.apache.org/jira/browse/TAP5-2140 https://issues.apache.org/jira/browse/TAP5-2027 https://issues.apache.org/jira/browse/TAP5-1918 https://issues.apache.org/jira/browse/TAP5-1883 https://issues.apache.org/jira/browse/TAP5-1845 https://issues.apache.org/jira/browse/TAP5-1803 https://issues.apache.org/jira/browse/TAP5-1772 https://issues.apache.org/jira/browse/TAP5-1741 https://issues.apache.org/jira/browse/TAP5-1661 https://issues.apache.org/jira/browse/TAP5-1640 https://issues.apache.org/jira/browse/TAP5-1634 https://issues.apache.org/jira/browse/TAP5-1611 https://issues.apache.org/jira/browse/TAP5-1606 https://issues.apache.org/jira/browse/TAP5-1512 https://issues.apache.org/jira/browse/TAP5-1404 https://issues.apache.org/jira/browse/TAP5-970 https://issues.apache.org/jira/browse/TAP5-805 This is comprehensive list, not ordered by priority. More comments interspersed... On Oct 27, 2013, at 3:35 AM, Dmitry Gusev wrote: > > I'm sure if you prepare well-tested pull request it will be accepted, but > you have to spend some time on it -- this is the price you should pay for > using open source for free. I don't have time for that. I am willing to pay to get my bugs fixed, out of my own pocket (my clients won't pay for it) > >> I originally built the FlowLogix library... >> Most of the functionality in there now is actually workarounds for > various bugs and missing features in Tapestry. > > Tapestry has one good ability to write workarounds for the bugs in client > code (via service overrides, decorators, etc.). > If you have some of the bugs fixed in FlowLogix I'd recommend to separate > the fixes to some FlowLogix sub-project and write some guides to > corresponding JIRA issues on how to apply the workarounds you've already > implemented. I have all fixes documented pretty well in the wiki. As we go forward to T5.4 and beyond, I don't see that trajectory as sustainable in the amount of time that I have to spend on this. Also, if you do split up the library into many modules, you will have 10 of them or so, a nightmare to maintain. None of these bug fixes are something that somebody wouldn't want anyway, no reason to make them that granular, the whole library is only 100k > > I'm sure it is possible to write most of the workarounds as a separate > tapestry modules. I'd maybe even used strategy of one tapestry submodule > per one bugfix. Maybe name those modules like FixForXXX and if I want your > workaround in my project I'd add this modules as a submodule to my > AppModule. > Already done in FlowLogix library (see my comments re: one-per-module above) that would make too many modules, and I don't have time to create / maintain all of them > > > > On Sun, Oct 27, 2013 at 10:40 AM, Lenny Primak <[email protected]>wrote: > >> Some of the issues I am having is more design-oriented, >> and a patch would not be a simple thing to do. >> >> Also, in order to produce a patch (with tests) a lot of work needs to >> happen. >> That work, for example, for someone like me will take 10x as long as >> for someone already familiar with the Tapestry code, or the part of the >> code that I am trying to fix. >> When someone already has built Tapestry environment / Selenium test >> environment, >> i.e. a Tapestry committer, the work will take much shorter amount of time. >> With all due respect, this isn't the best use of my time right now, >> as I have booked for more work than I can do in a day, every day. >> I want to be working on my clients' code, not Tapestry code. >> I don't want to have to get Selenium to work (which never worked in my >> environment) >> Our clients are not that advanced and we don't have integration testing, >> but we do a lot of unit testing. >> I just want to use Tapestry, report issues, and have them fixed. >> >> This problem perpetually exists in the Tapestry community, >> there are plenty of (valid) reasons for it (as you mentioned) >> but I am looking for a solution, which doesn't involve me >> spending more and more time on it (which I certainly do not have) >> >> On Oct 27, 2013, at 12:00 AM, Kalle Korhonen wrote: >> >>> Most if not all of the committers are in the same boat as you are. They >>> have already risked their own time and energy to patch issues themselves >> so >>> many times that the previous committers thought it's simply easier to >> give >>> commit access to this person than to keep applying his patches. >>> >>> All software has bugs but Tapestry's codebase is in general very mature, >>> well tested and well thought out. Tapestry committers have, for various >>> reasons, decided that the benefits of using Tapestry outweigh the >>> drawbacks, even when patching issues themselves. Everybody needs to do >>> their own benefit analysis. In terms of user base, Tapestry has one of >> the >>> largest among Java web frameworks. >>> >>> The most certain way of getting your issue fixed is supplying a patch >> with >>> test. It doesn't always get applied or it doesn't get applied without >>> changes. If you think it's difficult to get a patch applied to Tapestry, >>> you should try kernel development first. >>> >>> Kalle >>> >>> >>> >>> On Sat, Oct 26, 2013 at 6:31 PM, Lenny Primak <[email protected] >>> wrote: >>> >>>> Hi guys, >>>> >>>> I am struggling with a problem - how to get bugs (that I care about) >> fixed? >>>> I am building web apps for clients that run on Tapestry. >>>> I am finding that I am spending more and more time working around >> Tapestry >>>> bugs. >>>> The time that I spend fixing / working around bugs in Tapestry is the >> time >>>> I don't spend building >>>> and fixing my own applications. This isn't a good situation. >>>> >>>> I originally built the FlowLogix library to bridge Tapestry with JEE, >> and >>>> Shiro (via Tapestry-Security) >>>> Most of the functionality in there now is actually workarounds for >> various >>>> bugs and missing features in Tapestry. >>>> I always file a JIRA for every one of them. Minority gets fixed (after >>>> much begging) but majority isn't getting fixed. >>>> >>>> I know there are a lot of JIRA issues and few committers. I also know I >>>> can submit patches, but this can be dicey as well, >>>> as that takes committers' time and energy. Risk for me is that I can't >>>> spend time creating patches that don't get applied, or >>>> get rejected because I don't have a separate test (even though it's >> mostly >>>> enough that it doesn't cause a regression, >>>> which is covered by other tests) >>>> >>>> I also know Tapestry community is small, and volunteer, so this problem >>>> doesn't really surprise me. >>>> Right now, I am at a point that is getting unsustainable in this manner, >>>> especially since so many changes are >>>> happening in T5.4, which brings much more work and more bugs to fix. >>>> >>>> I'd like to know if any committers want to help solve this problem? I >>>> know it can be solved. >>>> What can be the motivating factor in getting these bugs fixed? >>>> >>>> I will even go as far as paying for the fixes. My clients won't pay for >>>> me to fix Tapestry, >>>> so I would have to pay out of my own pocket, just so I don't have to >> lose >>>> time fixing Tapestry myself. >>>> Any other suggestions? >>>> >>>> Same applies to Tynamo project as well. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
