On Sun, Oct 27, 2013 at 6:03 PM, Lenny Primak <lpri...@hope.nyc.ny.us>wrote:
> 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 > > By modules I mean not maven/gradle sub projects, but tapestry modules which are simple Java classes: one module -- one class. No need to add these modules to auto discovery via manifest. Users may include these modules by using @SubModule on their AppModules. I see no extra-overhead here. Your assumption about "everybody want my fixes" is wrong, I don't want them in my project if they come with 3rd party library that has tons of extra dependencies like JEE stuff, etc. Also I want the ability to opt-out some fixes if I have better workaround for them. That was my point. > > > > 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 <lpri...@hope.nyc.ny.us > >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 <lpri...@hope.nyc.ny.us > >>> 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: dev-unsubscr...@tapestry.apache.org > >>>> For additional commands, e-mail: dev-h...@tapestry.apache.org > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > >> > >> > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
