You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tapestry.apache.org by Lenny Primak <lp...@hope.nyc.ny.us> on 2013/10/27 02:31:11 UTC

Tapestry Bugs - How to get them fixed?

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

Re: Tapestry Bugs - How to get them fixed?

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.

On Sun, 27 Oct 2013 08:26:46 -0200, Dmitry Gusev <dm...@gmail.com>  
wrote:

> 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?

Only if Tapestry leaves the Apache Software Foundation. On the other hand,  
it (the Tapestry sources mirror at Github) could be used as a way for  
providing patches, I guess.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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

Re: Tapestry Bugs - How to get them fixed?

Posted by Dmitry Gusev <dm...@gmail.com>.

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 <dm...@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 <lp...@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
>



-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: Tapestry Bugs - How to get them fixed?

Posted by Dmitry Gusev <dm...@gmail.com>.

 Jochen, what you're talking about is actually GitHub Pull Requests -- they
do exactly this.


On Mon, Oct 28, 2013 at 11:34 AM, Jochen Berger <fo...@gmail.com> wrote:

> Am 27.10.2013 15:03, schrieb Lenny Primak:
>
>  Quick Jira search reveals bugs I care about:
>> Basically, this is a result of a search of issues that
>> are reported by me, voted on my me or watched by me:
>>
>
> Maybe we can find a way to better mark "low-hanging fruit", i.e. use JIRA
> labels to point out, which issues have patches attached and which ones
> include tests and so on?
> What about putting up a Wiki page with guidelines that patch writers
> should stick to when they submit patches?
> I think there are a lot of open issues with patches dangling around with
> no committer taking care of them (not even by commenting on them or
> requesting improvements). I find it quite annoying to find issues,
> submitting patches and not getting them applied because (at least that's
> what I suspect) they are to hard to find for people with commit access.
> What do you think of the following (not necessarily in that order)
>  * Let's use the "patch" label for all issues that have a patch attached
>  * Find all issues that have an attachment but do not have the
>    "patch" label and assign it to them if the attachment is a patch
>  * Create the Wiki page with the patch guidelines and link it with JIRA
>    so that everybody who submits a patch will have to read it. Maybe
>    even post a comment with link to the page on all open issues with
>    patches
>
> I think there's already a lot of improvement up to here. If you're a
> committer and can't sleep at night, just filter for open issues with the
> patch label.
> Now for the time-consuming tasks:
>
>  * Go through the issues with the "patch" label, check if they contain
>    a test and apply the "contains-test" label
>  * Go through the issues with the "patch" label, check if the patch
>    applies cleanly to master and, if it doesn't, ask the committer to
>    rebase it and apply the "needs-rebase" label
>
> I guess, some of this can be done by a script, at least the second task.
>
>  * Go through the issues that have the "patch" and "contains-test"
>    labels but not the "needs-rebase" label and apply the patches or
>    leave a comment what needs to be improved.
>
> I know, some of this will take a lot of time, but I think, it can help us
> in getting some of the good patches that are already there applied and
> encourage people to write patches.
> And the best thing is, only the last part has to be taken care of by an
> actual committer, all the tinkering with the labels can be done by any
> regular JIRA user.
>
> Jochen
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com