On Oct 27, 2013, at 6:57 PM, Kalle Korhonen wrote: > 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've been doing software development for 25 years. Nothing surprises me anymore, whether on the expensive, or the cheap side. I want to facilitate the solution here. I am going to pay out of my own pocket, because I feel that's how I can contribute to Tapestry more than my time right now. > 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. I would like to keep it in private for now. If Thiago (or any other committer) wants to take this on, please email me. > > 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. But then I am on the hook for maintaining it, tracking incompatible changes, etc. for the rest of my life. This happened in 5.3->5.4 transition, every one of my fixes that I have in the FlowLogix library got broken, and I spent countless unpaid hours updating this. I do believe I have and I am contributing a lot in code / time to Tapestry community. I've been answering questions for a long time, wrote a JEE bridge component library, which is Apache licensed, and even helped evangelized Tapestry through networking. > 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. Absolutely understandable. Trying to find a solution to the above-described problem. > > 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. Yes, but I think there are too few active committers in Tapestry, for the amount of users / issues that come up. Other open source projects are a lot more active about fixing issues with a lot more committers doing 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 <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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
