I can also see one technical difficulty that prevents quick patches -- this is JIRA.
JIRA is not the right tool for providing patches for a git project. Looking at other open source projects that are hosted on GitHub you can notice how many pull-requests are done for them. Having pull requests being one-click away from being applied is very important I think. I'm not sure if this is some Apache requirement that Tapestry must store its codebase on Apache's git repo, but there is a Tapestry 5 mirror on GitHub: https://github.com/apache/tapestry-5 Though very few people know about it, maybe because it's not mentioned here: http://tapestry.apache.org/community.html#Community-SourceCodeAccess There is also no activity on GitHub, there is even no Issues section in there. And also zero pull-requests and no README.md with some simple instructions how to contribute. Not sure if somebody from the dev team has access to this repo, but maybe we should change this: enable issues and accept pull requests from GitHub? Will they be synced back to Apache's repo? If yes, maybe we should start using GitHub repo as a primary repo for tapestry development? On Sun, Oct 27, 2013 at 11:35 AM, Dmitry Gusev <dmitry.gu...@gmail.com>wrote: > 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 <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 > -- Dmitry Gusev AnjLab Team http://anjlab.com
