On Sun, Oct 27, 2013 at 7:03 AM, Lenny Primak <[email protected]>wrote:
> 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) > Well this a marriage made in heaven then. Thiago awhile ago said he'd be willing to prioritize his bug fixing list based on pay/donation. I think this might just work but don't be surprised how expensive it is to write custom software by an expert. I guarantee though you'll be able to get them fixed quick once the pay is right. I think Dmitry is totally right saying that you should just focus on one issue at a time. If you want to keep it public, just set a price for a few of your highest priority ones, publish it here and see if anybody bites. If not, just contact individuals or wait them to contact you. Still, you say you don't have time to do it yourself but you have time write the email. I suspect that in reality, you'd like to get the bug fix but getting it fixed is just not high enough on your priority list. Yeah, I totally get the "it takes 10x for me" but even if working on open source takes time from you, it also gives back. Your next bug fix will be that much easier and faster and you learn a lot. The group of committers is not an organization whose sole mission and highest priority is to make Tapestry work for as many people as possible. It's just a group of individuals with their own missions, desires and priorities. Until your issue scratches the itch of a committer, it's quite possible it's not going to be anybody else's top priority any more than yours. Finally, it would have been equally correct to say this problem perpetually exists in the open source world. Any successful project is struggling with the same issues. There's always more ideas and new use cases than there are hands that do the work. We should investigate integrating (and advertise making!) pull requests, I think that's quite possible nowadays and I believe some Apache projects are already doing it. Kalle > > > > >> 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] > >
