Developers, please don't ignore reported GWT issues.

Martin Ždila

unread,

Oct 4, 2011, 4:40:31 AM10/4/11

to google-we...@googlegroups.com

Hello

GWT is a perfect toolkit but there are still many small but frustrating issues open in bug-tracker and GWT developer team seems to be ignoring them for many months or even years. GWT issues seems not to be maintained very well as there are many of them not closed but are already fixed in the SVN, for example:

Many issues are moved from milestone to milestone for a long time. I personally don't need features like GPE but rather serious GWT without any critical issues. IMHO there should go the focus.

My starred and very annoying issues are:

Also I am missing documentation of validation (JSR-303). Validation is really very important feature for GUI framework and it should be in GWT maybe in pre 2.0 version.

Please take a time to focus to the most critical issues and tidy up their state. Our CTO is actually thinking to use more lightweight solution like jQuery just because of all this frustration (mostly because GWT is not very OSGi friendly) :-(

Thanks in advance!

Stanislav Ievlev

unread,

Oct 4, 2011, 6:14:53 AM10/4/11

to google-we...@googlegroups.com

+1

04.10.2011 12:40 пользователь "Martin Ždila" <m.z...@gmail.com> написал:

> Hello
>
> GWT is a perfect toolkit but there are still many small but frustrating
> issues open in bug-tracker and GWT developer team seems to be ignoring them
> for many months or even years. GWT issues seems not to be maintained very
> well as there are many of them not closed but are already fixed in the SVN,
> for example:
>

> - http://code.google.com/p/google-web-toolkit/issues/detail?id=4392
> - http://code.google.com/p/google-web-toolkit/issues/detail?id=1534

>
> Many issues are moved from milestone to milestone for a long time. I
> personally don't need features like GPE but rather serious GWT without any
> critical issues. IMHO there should go the focus.
>
> My starred and very annoying issues are:
>

> is even a patch attached)
>
> Also I am missing documentation of validation (JSR-303). Validation is
> really very important feature for GUI framework and it should be in GWT
> maybe in pre 2.0 version.
>
> Please take a time to focus to the most critical issues and tidy up their
> state. Our CTO is actually thinking to use more lightweight solution like
> jQuery just because of all this frustration (mostly because GWT is not very
> OSGi friendly) :-(
>
> Thanks in advance!
>

> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/ZF1XevCV6FEJ.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>

Juan Pablo Gardella

unread,

Oct 4, 2011, 8:31:01 AM10/4/11

to google-we...@googlegroups.com

+1

2011/10/4 Stanislav Ievlev <stanisla...@gmail.com>

stuckagain

unread,

Oct 5, 2011, 3:41:09 AM10/5/11

to google-we...@googlegroups.com

I have been frustrated with this as well and voiced my concern before. But all they keep on doing is adding features that most of us don't need.

GWT is great, but there is a lot of old stuff in there that is half baked and nobody in the GWT team seems to be concerned with actually fixing bugs.

When I complained about it the only answer (if any) I get is: you are free to send us a patch.

Most of us don't have the time, or even the right to spend our time on working on code for google during our day jobs. And in the evening we need to take care of our family so fixing anything taking more than a few lines of code is totally impossible.

I managed to patch one of the issues I reported, but some things are hard to fix unless you really know the GWT internals very well. There is a bug in the Event dispatching after opening a popup in IE and I really don't know how to fix this one since it goes really deep into the root event handling implementation. There is no developer docs available that explains the architecture and the devs that created the code in the first place are doing other things. I filed the bug report, I wrote in GWT and GWT contrib newsgroups and got 0 responses...

This is the one:

http://code.google.com/p/google-web-toolkit/issues/detail?id=4938

From what I read on google culture it seems like you only get rewarded for writing new stuff, not fixing old stuff (unless it affects a google product launch).

l.denardo

unread,

Oct 5, 2011, 5:37:30 AM10/5/11

to Google Web Toolkit

Some time ago I stepped into the issue lifecycle wiki page.

http://code.google.com/p/google-web-toolkit/wiki/BugTriageProcess
http://code.google.com/p/google-web-toolkit/wiki/ManagingMerges

Maybe this can clarify some things about why issues are not updated
(looks like most of times this is an expected behavior).
And yes, I agree this information should be more visible to people
reporting issues :-)

Regards
Lorenzo

Martin Ždila

unread,

Oct 11, 2011, 12:01:01 PM10/11/11

to google-we...@googlegroups.com

It seems that after my post there started a tidying up of issues. Most of them turned to "PatchesWelcome", even those trivial to implement. Also my newly reported issues turn to "PatchesWelcome". Does it mean that GWT developer team will not implement it and waits for GWT users to do it? Or does it mean that patches are welcome, but if none arrive then GWT development team will fix it?

Thomas Broyer

unread,

Oct 11, 2011, 12:15:57 PM10/11/11

to google-we...@googlegroups.com

On Tuesday, October 11, 2011 6:01:01 PM UTC+2, Martin Ždila wrote:

It seems that after my post there started a tidying up of issues.

That's right (though I don't know whether it's because of your post, or they just coincidentally happened at about the same time)

Most of them turned to "PatchesWelcome", even those trivial to implement.

Particularly those trivial to implement I believe. Review a trivial patch and applying it is way faster than writing in the first place (particularly as you want to have unit tests, and/or manual tests).

I believe applying a patch from gwt-code-reviews.appspot.com is just one click for the GWT team, so it really isn't what takes the more time.

Also my newly reported issues turn to "PatchesWelcome". Does it mean that GWT developer team will not implement it and waits for GWT users to do it? Or does it mean that patches are welcome, but if none arrive then GWT development team will fix it?

The former: http://code.google.com/p/google-web-toolkit/wiki/BugTriageProcess

At least until projects within Google need it and provide the patch/ask the GWT team to fix it.

Jeff Larsen

unread,

Oct 11, 2011, 12:20:19 PM10/11/11

to google-we...@googlegroups.com

I'd recommend trying to provide your own patches. GWT is a community effort and as such it needs more than just the support of google. You'll almost certianly learn something in the process aswell, so it really is win/win.

Jens

unread,

Oct 11, 2011, 12:21:36 PM10/11/11

to google-we...@googlegroups.com

"Marking something as "PatchesWelcome" means that we do think it is a good idea, but it ls likely not something we are going to do ourselves any time soon. We will, however, happily accept, review, and integrate high quality patches that implement this behavior. Issue 6401 is a perfect example of something that could be implemented by the community (and probably fairly quickly)."

Taken from https://groups.google.com/d/msg/google-web-toolkit-contributors/DIwexDgjU-U/xmEgHYeZcioJ . Feel free to read the whole discussion.

Patrick Tucker

unread,

Oct 14, 2011, 9:22:43 AM10/14/11

to Google Web Toolkit

Providing your own patches doesn't guarantee it will get looked at...

I submitted the following patch because it was a simple and quick
first attempt at recommending a patch for GWT:
http://code.google.com/p/google-web-toolkit/issues/detail?id=6589

The patch got no attention from the GWT team, negative or positive, so
I don't bother putting forth the effort to submit real patches. I
realize the patch doesn't solve the communities problems, but that
wasn't the point.

Just my experience.

Thomas Broyer

unread,

Oct 14, 2011, 10:08:32 AM10/14/11

to google-we...@googlegroups.com

Patches should be submitted to http://gwt-code-reviews.appspot.com where, if you set reviewers, they will show in their "reviewable by me" (and they'll receive a mail).

As for your patch, a single JSNI method is faster in DevMode, because it only requires one roundtrip to the browser to execute it, so the proposed change really isn't worth it.

My own experience is that all my patches (submitted to gwt-code-review.appspot.com) were looked at (not necessarily immediately though), and a majority of them rolled in. And most, if not all, patches submitted to gwt-code-reviews.appspot.com have been reviewed (provided some reviewer was assigned, otherwise there's always the risk that it slips through in the flood of patches –public and private– they have to review).

Eric Clayberg (Google)

unread,

Oct 14, 2011, 4:46:11 PM10/14/11

to google-we...@googlegroups.com

If you follow the correct procedure for submitting patches, it should get looked at.

Attaching a patch to an issue won't get it looked at. You also need to sign a CLA and submit the patch to Rietveld.

Eric Clayberg (Google)

unread,

Oct 14, 2011, 5:08:38 PM10/14/11

to google-we...@googlegroups.com

It was somewhat of a coincidence as we were starting a small project to clean up and triage the issue tracker (which had been unfortunately neglected for awhile). We definitely took notice of your post and looked at each of the issues you referenced.

"PatchesWelcome" does indeed mean that we think it is a good idea, but it isn't something we are going to get to any time soon (making it a great opportunity for the community to contribute a patch). Depending on our own priorities we may or may not ever get to a given PatchesWelcome issue, so if it is something very important to you ("you" as in anyone in the community), I would strongly encourage you to create and submit a patch.

If you do submit a patch, it is important to follow the correct procedure for submitting patches. Simply attaching a patch to an issue (as was originally the in the case 6530) won't get it seen by the GWT development team. As you can see from case 6530, that patch has now been submitted to the right place, reviewed, and submitted.

As has been said by others and by us in the past, we are very much looking for community support and contributions. We will continue to step up our efforts to review and submit any patches that we receive.

Jens

unread,

Oct 14, 2011, 5:32:26 PM10/14/11

to google-we...@googlegroups.com

As you now have your small clean up project phase it might be a good time to update the duties column in http://code.google.com/p/google-web-toolkit/people/list or create a similar list as wiki page to help the community to decide which persons should be assigned for reviewing patches in Rietveld (http://gwt-code-reviews.appspot.com/).

Just assigning "someone" to a patch so it gets recognized (and later maybe reassigned) somehow doesn't feel right to me. I think its definitely better if the community can see who is active in the development team and who would be a good review candidate for, e.g. UiBinder patches, compiler patches, RequestFactory patches, Editor patches, ....

-- J.

Thomas Broyer

unread,

Oct 15, 2011, 3:35:29 AM10/15/11

to google-we...@googlegroups.com

On Friday, October 14, 2011 11:32:26 PM UTC+2, Jens wrote:

Just assigning "someone" to a patch so it gets recognized (and later maybe reassigned) somehow doesn't feel right to me. I think its definitely better if the community can see who is active in the development team and who would be a good review candidate for, e.g. UiBinder patches, compiler patches, RequestFactory patches, Editor patches, ....

I agree.

Though as a rule of thumb you can simply pick the last committer and last reviewer for the files you've modified (or lok at few commits back and pick the people who seem to be "maintainers" of that part of GWT).

Eric Clayberg (Google)

unread,

Oct 15, 2011, 2:33:55 PM10/15/11

to google-we...@googlegroups.com

That is good advice. In addition to the active GWT development team, there is a fairly large group of ex-GWT team members who are still committers on the project and working on it during their Google 20% time. If you happen to pick the wrong person, we should be able to correct it quickly.

Reply all

Reply to author

Forward