Every bug is individual and needs to be discussed separately. It would be good start to list all the bugs you're talking about here in this thread to be more specific.
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 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'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. 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
