tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lenny Primak <lpri...@hope.nyc.ny.us>
Subject Re: Tapestry Bugs - How to get them fixed?
Date Mon, 28 Oct 2013 04:28:00 GMT

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 <lprimak@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 <lprimak@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-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Dmitry Gusev
>>> 
>>> AnjLab Team
>>> http://anjlab.com
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message