Overuse of "AssumedStale" Issue Tag

[V.B.]

Recently, I have been getting several email updates about GWT issues that I had starred. The majority of these have been because the issue was tagged as AssumedStale. I fully understand the need for such a tag, but I think it has been overused in a few cases to the point of abuse. Specifically: I noticed that some issues tagged as Accepted (or at least Planned), are now listed as AssumedStale. I think that's taking it a bit too far. My interpretation here is that the aforementioned Accepted issues are no longer going to make into GWT. Have I misunderstood the situation? If not, is anyone else concerned about this?

[Daniel Kurka]

Hi there,

we have announced on Google IO this year that we can to clean up the issue tracker. The issue tracker had almost 5000 open issues and its clear that it needed work. We are on a very good path with cleaning up, but this still requires a lot of work. Lot of these issues are older than 2 years and no work has been done on them.

If you feel there is an issue that was closed and should not be closed feel free to reply on the issue (I should be on cc anyway) and we will look into it. Since GWT is an open source project you can help out and supply a patch for an issue that you feel is important.

We need the issue tracker to be a viable input for things that should be done with GWT and that is not possible with the vast amount of clutter we have in there currently.

-Daniel

[V.B.]

Hi Daniel,
   Thanks for taking the time to respond. I watched your IO video. Great job btw, and congrats on your new position at Google. I completely understand the need to clean out the issue tracker. It has certainly been neglected over the years. My primary concern over all else is for Accepted issues in general. Presumably these were issues that other Google engineers felt were important enough to mark for inclusion into GWT.

I understand now that GWT has the Steering Committee guiding it, certain priorities may have changed. That's fine, I accept that! However, as GWT continues to evolve, three questions come to mind:

1) Other than age, is there any other criteria for marking an Accepted/Planned issue as stale?

2) Moving forward, can we assume that any newly Accepted issues will be tackled in a reasonable time frame (i.e. not still floating around in 2016)?

3) How much weight does the Steering Committee give to heavily starred issues (i.e. the kind that are too large for individuals to tackle)? The top three open issues are:
java.util.Calendar emulation (483 stars)
WebSockets for RequestFactory (218 stars)
GWT-compatible Protocol Buffer Compiler (164 stars) <-- start with this one!

Again, thanks for taking the time to respond.

[Jim Douglas]

I just got that AssumedStale notification about a bug that I entered (6484).  It's not fixed and it's still an issue; it makes on-demand scrolling unusable (or at least flaky) in a CellList.  I get how satisfying it is to close a bug reports, but it's not helpful to close bug reports for bugs that still exist.

[Ed]

I am also confused ...

I understand the "cleaning up action" but don't understand certain bug/issues being marked as "Stale" that have many votes... (like mentioned above)

Maybe an idea that the gwt dev team adds additional comments to these "kind" of issues such that we get a better understanding. 

And it keeps me motivated to submit issues, which is certainly not the case the way it's going now (not to speak about the misunderstanding I had with Thomas this weekend over an issue)

What about "patch welcome"..? 

I don't have good experience with this in the past: you put on a patch, and no review is done, or it's not accepted, etc... so they end up dead after a few years just like the issue.

Why will this "really" be different ?

Sorry, like to think positive but that is hard currently...

[Thomas Broyer]

On Monday, May 27, 2013 2:25:28 AM UTC+2, V.B. wrote:

3) How much weight does the Steering Committee give to heavily starred issues (i.e. the kind that are too large for individuals to tackle)? The top three open issues are:
java.util.Calendar emulation (483 stars)

As said on the issue, there's no plan to emulate java.util.Calendar because it cannot be emulated "well enough".

We're waiting for JSR310 in Java 8, which should (a priori) be better fit. I'm concerned that all the JodaTime ports are now dead and buried though, which makes me wonder how much people rely on date/time in client code…

Comment 66 is still relevant: https://code.google.com/p/google-web-toolkit/issues/detail?id=603#c66

WebSockets for RequestFactory (218 stars)

Note that the request is about server-push. I believe Google uses their own "channel API" which is not open-source (part of it is in Closure Library), so they're unlikely to contribute the code here. Others have used GWT-Atmosphere, SocketIO or plain WebSocket (Apache Wave use the latter two).

The problems are:

• make it work in DevMode (there was an attempt to update DevMode to Jetty 7 which supports WebSockets, but it had to be abandonned because of classloader issues IIRC)
• make it work cross-browser with fallbacks (à la SocketIO or GWT-Atmostphere, but then, well, there's SocketIO and GWT-Atmostphere already, so why not just use one of them?)
• layer a high-level protocol on top of it (and BobV proposed using RequestFactory, which is why this issue is now labeled "websockets for RF", because it's "symmetric" he says –at least the client and server both know how to parse requests *and* responses, contrary to GWT-RPC– but I have a hard-time finding how that would play with the ValidationTool, locators, service locators, etc. should all these things be used on client-side? should it be restricted to ValueProxies with no locators? what would the API look like?). Many people have many different needs; some will want something "RPC-style", others more like an Event Bus just passing messages (but then there's Errai already, so why not just use it?)
• and on the server-side, server-push is useless without some sort of event bus (you don't want to use a static map/list of connected clients, that wouldn't work in a cloud environment), and all deployment targets have different capabilities so there would be a need for an abstraction there too (does that exist already? it's not specific to GWT so there's no reason anyone would have give it a go already).

 

GWT-compatible Protocol Buffer Compiler (164 stars) <-- start with this one!

What do those people want actually? A way to turn .proto files into "something" usable in GWT? Possibly with support for services? Should the server-side implementation of those services use protobuf-java-generated classes?

Or do they rather want an emulation of protobuf-java so code can be shared between the client and server? (how about services then?)

Are all those people really interested in this or are all those starts more about "protobuf looks cool, and it's made by Google which builds cool things that scale, so protobuf must be great for me, let's just see what happens there"?

Now that Square released protoparser, I'd like to revive my protobuf-gwt project, but I have to find some time first (and it requires a major rewrite of the existing code), and there haven't been much traction in the past years (are people rather using protostuff or some other lib? or are they following Wave's approach of using reflection on classes generated by protobuf-java to generate other GWT-specific things?)

For the latter two issues above, also note that our goal is to modularize GWT and externalize things (make GWT smaller, but then easier to maintain), so new features that can be built on top of GWT (rather than needing changes into GWT proper) are unlikely to be added "to GWT", but rather be created as companion projects (just like gwt-mockito and gwt-eventbinder, recently released by Google). So it's unlikely that those 2 issues will ever be fixed "in GWT proper".

[David]

I am happy to read that I am not the only one who has this feeling.

 

And I don't agree with using purely the number of stars to drive the triage. Certainly taking 100 as a minimum is extremely high if you consider the small number of advanced GWT developers (who would bother reporting these issues).

 

A bug is a bug, it is really painful if you are on a deadline. So we reported these issues to avoid that others need to stumble over these.

 

David

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ed]

And I don't agree with using purely the number of stars to drive the triage. Certainly taking 100 as a minimum is extremely high if you consider the small number of advanced GWT developers (who would bother reporting these issues).

Totally agree. 

If you wait till people vote the issue such that enough stars arise, as a framework you are getting behind. 

To be an innovative tool/framework you should build/add/solve issues/features  when "needed" to be ahead of others and motivate people/company to choose your framework..... If they don't see "certain" features (for them important), they might choose another framework...

[V.B.]

Hi David and Ed and Jim,
    Thanks for chiming in. I'm glad I'm not alone. I completely agree that bugs should come first, period. That goes without saying. My previous question about weighing by stars was intended to be specific to enhancements and feature requests. You're right, bugs should never be weighed by stars.

I think GWT is going through some growing pains right now, and I feel this is exactly the kind of discussion that needs to happen. All the better that Daniel K. and Thomas B. are chiming in as well.

David, I saw your recent comment in issue 1328, and you made some very good points. In particular, you reminded me that many GWT users (probably the vast majority) are working in the corporate sector and need GWT to be a professional-grade tool. I can also relate to your point about having to come up with a workaround, and then not being able to contribute it back. I'll probably post back here with your full comment.

Thomas, thanks for your in-depth response. That was very thorough. I intended my questions to be more general though (I was just citing the top open issues as an example). After bugs, which come first, does the Steering Committee have some set protocol for triaging issues (questions 1 &  3, above)?
And a follow-up question: Making GWT more maintainable makes perfect sense, so I understand the need to modularize GWT by externalizing several components. But, does that also imply that the Steering Committee as a whole would be effectively washing its hands of any responsibility to externalized components?

By the way, I do want to give props to Daniel and Thomas for entering the discussion so quickly. It's a nice change from the AppEngine forum where we often feel left in the dark.

[V.B.]

Posting David's comment (in blue) from Issue 1328:

#8
[Issue marked as AssumedStale]

#9 (David)
Hey, why make this stale? When you are using IFrames in applications you really need more events than GWT is offering.

#10 (Thomas)
... and yet, in almost 6 years:
  * only 9 people starred the issue
  * no one provided a patch
  * the issue hasn't been updated for years...
If you provide a patch, we'll gladly review it and update the issue status accordingly.

#11 (David)
- The only bugs that reach 100+ votes are probably critical bugs.
- This particular bug was accepted, it would have taken a few hours to implement.
- In the mean time I obviously already used JSNI to work around the issue, as most people probably did. I am not allowed to contribute this by my employer.
- But it is a maintenance problem in bigger projects because we need JSNI tricks to be able to extend existing GWT widgets (the widget designs are very restrictive). So we rather just replace them completely.
- In fact people who needed more advanced widgets went for GXT or some other widget set and as a consequence it is normal that these kinds of bugs don't get a lot of exposure. I have been exposed to about 10 large GWT projects at multiple companies and none of them are using the core GWT widgets due to a lack of features.

[Ed]

For the latter two issues above, also note that our goal is to modularize GWT and externalize things 

How will this look like?

To my experience, currently it's very hard to  change/extend GWT core functionality. How will this change?

A few examples that popup: the classes Event, Element, HandlerManager (there are more) are very hard to change/extend because the methods/classes are final, or package protected or lack of interface usage.

Looking at the changes issues (AssumedStale) I don't get the impression that this will change soon as the issues about making classes like Event, Element, HandlerManager, etc... more flexible such that they can be extended, or all marked as "Not-Planned", "as-Designed", "AssumeStale"... 

Also a few issues about making more use of interfaces are "destroyed", which I think is needed to make GWT more "modular".

Please more insight?

[Thomas Broyer]

Modular in the sense that gwt-user.jar will be split into smaller parts and you only include in your classpath the modules you need.

 

[Ed Bras]

Thanks, was a afraid of that ;)...

So still difficult to extend/change core gwt functionality like mentioned above.. :( (it's time to become a contributor ;) )

 

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/5aNsIcPKDm4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[brad]

Stale implies that these bugs no longer exist, ASSUMESTALE I suppose means that whoever is closing the bug doesn't even care enough to check to see if the bug exists or not, but presumes that it doesn't. Since I've seen very few bugs fix themselves I have no idea where this presumption comes from. WONTFIX is a much better fit. That acknowledges that there is a bug, but for whatever reason no one wants to fix it. Which with the 'you could have submitted a patch yourself' response, seems to be exactly what's going on here.

[Timothy Spear]

What some call a bug others call a feature. Since bug is generic for all issues, features, and requests making the assumption that won't fix is also equally invalid. Unless you are going to spend the time and effort to validate all the items you are making a large presumption upon others.

Tim in a very sarcastic mode.

On Jun 3, 2013 10:42 AM, "brad" <bra...@worldviewsoftware.com> wrote:

Stale implies that these bugs no longer exist, ASSUMESTALE I suppose means that whoever is closing the bug doesn't even care enough to check to see if the bug exists or not, but presumes that it doesn't. Since I've seen very few bugs fix themselves I have no idea where this presumption comes from. WONTFIX is a much better fit. That acknowledges that there is a bug, but for whatever reason no one wants to fix it. Which with the 'you could have submitted a patch yourself' response, seems to be exactly what's going on here.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

[Mauro Molinari]

I think Thomas's comments on http://code.google.com/p/google-web-toolkit/issues/detail?id=6962 and the "spring cleaning" thing say it all on the attitude of GWT devs toward bug reports: they are just an annoyance and the fact that the issue tracker has a lot of very old reports (not even considered for years) is just the reporters' fault. After all, GWT is quite perfect as is and many supposed bugs should have fixed themselves during the years, or are just invalid.

Feel free to provide patches, although they probably won't be reviewed at all, since your reports usually just matter to you and few others.

I'm really sad :-(

Mauro.

[David]

Mauro,

I have the same feeling. It seems like nothing has changed since GWT being detached from Google. 

After years of neglecting the loyal developers, who devoted time to report issues that were bugging us, 

we just got slapped in the face. We are now officially allowed to fix the bugs ourselves - and maybe 

after spending our free time on this, just maybe they will take our fixes.

This attitude does not give me a lot of confidence that GWT is going the right direction, so I will probably 

be holding off in advocating GWT as a dependable tool for enterprise developments. Bug fixes are way 

more important than new functionality. We have to support our software for 10 years, we need to be able 

to depend on a professional attitude towards bug fixing.

Look at the code base now:

- 4 different ways of handling events (Listeners, Handlers and 2 event bus implementations - which should I choose ?).

- CssResources are not really usable with style dependent naming as used in most of the widgets so I need to mark as NonStrict or use @external all over the place.

- GWT RPC is not fast enough and causes stackoverflow and slow script warnings (well after years of waiting that bug will be resolved by moving to IE9).

- DeRPC was supposed to fix the deficiencies of RPC but it got scrapped

- RequestFactory is the new kid in town, but let's face it, it is no that easy to start with because we are not all pushing JPA Objects straight to the browser. We have our own JDBC layer that works much faster than most JPA compliant implementations.

- LayoutPanels vs regular panels, watch out when mixing.

- No full featured table implementation. 

- No CellTree (basically a big lack of decent components that  are completely inline with all optimisations that GWT allows)

- ... I'm sure others can add to this list, this is just the first things that comes to mind.

and those are just the first things that comes to mind.

David

--

[Mauro Molinari]

Il 04/06/2013 09:24, David ha scritto:
> This attitude does not give me a lot of confidence that GWT is going the
> right direction, so I will probably
> be holding off in advocating GWT as a dependable tool for enterprise
> developments. Bug fixes are way
> more important than new functionality. We have to support our software
> for 10 years, we need to be able
> to depend on a professional attitude towards bug fixing.

I totally agree with this.

> - ... I'm sure others can add to this list, this is just the first
> things that comes to mind.

I also struggled with many of the points you are listing.

I would add this: they are going to remove the "dev mode" and the
browser plugins. Hence, no more way to debug in Java, but rely on the
"dramatically" fast (!? takes dozen minutes to compile a bunch of
modules on my machine...) GWT draft compilation and the JavaScript
debugger of your browser (i.e.: Chrome, since it's the only one that
supports many features needed for this purpose), alias "super dev mode".
This also scares me and IMHO cancels one of the main GWT strengths (the
ability to debug code using the excellent Java tooling out there).

Mauro.

[Ed]

@David, @Mauro,

I am surprised and disappointed by your reactions.

My reaction on this all:

Please be positive and not so negative. Clearly your glass is half empty and mine is half full (and I am using GWT for about 7 years now)...

Please follow the GWT news, G+ GWT posts, Ray Google 2013 GWT session, the issues being solved blazing fasts currently..., the contributor forum, etc...

I am sure that if you follow these sources, your glass will be half full as well. If not, please see a doctor ;)...

@David: your list of negative points is incorrect as I am building huge gwt projects and don't have this experience of 80% of your issues. So you might want to consider refactoring/reviewing your code/GWT usage.

GWT had a tough year putting all pieces in place, but I think things look very promising which they  are showing if you follow the above sources...

[Mauro Molinari]

Il 04/06/2013 09:50, Ed ha scritto:
> I am surprised and disappointed by your reactions.
> My reaction on this all:
> Please be positive and not so negative. Clearly your glass is half empty
> and mine is half full (and I am using GWT for about 7 years now)...
> Please follow the GWT news, G+ GWT posts, Ray Google 2013 GWT session,
> the issues being solved blazing fasts currently..., the contributor
> forum, etc...

It's hard to be positive when:
- you have starred about 10 issues which received no updates for
months/years, some of which are so critical that it's surprising they
never got fixed
- you now see your starred issues closed as "AssumedStale" one by one,
without any evaluation or feedback either
- you ask for clarifications and you are said that you're the only one
interested on those non-bugs
- you are said that it's a waste of time to review your bug reports

Mauro.

[David]

Ed,

You are right that my glass is half empty, but that is just my character ;-)

I've been using GWT since it was first introduced, I loved it straight away - coming from a Motif/JBuilder/Swing background.

I am still hoping that they manage to get this back on-track, but I just hope that they put a little more focus on bug-fixing.

It is really frustrating that about all the issues I ever reported where put on assumed stale. I spend a lot of time to detect and report these. In the mean time I have worked around many of them (JSNI to the rescue!) and I guess a lot of other people have done the same. But for new people starting out with GWT, this is not easy.

You might now have experienced the same issues, but all applications stress the browsers differently. We need to send a lot of data over RPC and that was just plain bad on older IE. Our software runs over fast networks, so the bandwidth is not the issue. But the browser limitations in IE7/8 were. I moved on to JSON for my RPC needs and it moved from minutes to less than a second in some cases.

David

[Ed Bras]

Of course I recognize the pain and a few weeks ago I have to admit I was less positive then now..

But in the mean time many things have happened, issues are being fixxed as we speak...

Yes, I also have a lotttt of issues that are put on AssumedStale... But that means they get a lower priority, not that they are forgotten!..

Please put yourself in their position (GWT dev member)... 

Imagine you just entered the GWT dev team and have to clean up 5000 open issues ?... What would you do ?... 

Of course it's a bad thing that it got this far, but taken as it is, Google had their own private gwt issue tracker and hardly used the public issue tracker (follow the sources please)...

All these things have changed, contributors are joining the gwt development and things are being picked up quicker then before... 

Patient please, see it as GWT just started as it's completely different "thing" now..

I understand your "complaints", but please turn them around in "help"... 

The way things are setup now, it's very easy to contribute code to to the Trunc, others will review it, and accepted (if your lucky ;)...

This setup certainly invites me (and others) to do this...

Like mentioned, every body stresses/usages the browser differently, that results in different kind of issues. As such, it might be hard that your issues get  attention. The more reason to pick them up yourself and contribute (in the past contributing was hard, as google had strict rules, that all changed now)...

BTW: this is nothing... Hibernate is/was much worse ;)... The Hibernate dev team would hammer you down ;)....

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/5aNsIcPKDm4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[Ed]

Wouldn't be cool that many gwt developers (like us) would get permission of their boss/manager to contribute about 2 hours to GWT ?

Imagine that around 100 developers around the world would do that? -> 200 hours/week of GWT extra development time ;)... 

I am certain many issues get fixxed ;) 

To my experience, may bosses don't mind and put it under "research & development"

[Mauro Molinari]

Il 04/06/2013 10:36, Ed Bras ha scritto:
> Please put yourself in their position (GWT dev member)...
> Imagine you just entered the GWT dev team and have to clean up 5000 open
> issues ?... What would you do ?...

I would start to evaluate them to see if they need a fix or not, and put
a priority on them.
Unless you think the reporters are all happy to waste their time to open
tickets, I think that those bugs were opened for a reason. So, for me
they're actually a resource, rather than a burden.

Mauro.

[Thomas Broyer]

On Tuesday, June 4, 2013 10:19:27 AM UTC+2, Davide Cavestro wrote:

@Ed

I really hope you are right... but so far I've had the same feelings of Mauro and David

I guess some discouragement/vexation could be avoided adding an explanatory comment before or contextually tagging an issue as AssumedStale, and especially avoid stating

I spent more than half an hour reading the code and the specs and doing tests. We can't realistically spend as many time on each and every opened issue. 

That really makes me wonder...

The quote above is out of context: it was a reply to Mauro's "This is the kind of feedback I would have appreciated before setting the AssumedStale keyword."

So let's try again:

1. the issue tracker has been neglected for years, leading to many issues open and never triaged; we need to clean that up
2. we can't realistically spend half an hour for each and every of these issues: 1500 issues or so would take 750 man×hour, and nobody works full-time just on this (that'd be 100 workdays, i.e. 5 months, if one person were dedicated full-time verifying issues before closing them; surely we can spend everyone's time better)
   
3. so as Ray Cromwell says, the only viable option is to "crowd source": when in doubt, close the issue and see if someone complains, and then only spend time on that issue.

Then we have to set priorities, because we're not paid to work on GWT (some Google employees are, but their priorities are the ones of Google; this is the reason why the issue tracker had been neglected for so long and why Google chose to make GWT more open by forming the Steering Committee).

On the issue Mauro points out and many others where Daniel replies with "feel free to provide patch", we can reopen it but if nobody spends the time to fix it, in a year from now we'll have the same mess in the issue tracker. On that specific issue, I could change the status to NotPlanned (so it's still closed, but removes the word "stale") but would it change anything to the way the issue is handled after that? No. (though if you think NotPlanned would be better than AssumedStale, I can make that change).

I've had issues open for years, patches pending review for months. I've been there. Daniel also closes some of the issues I reported some time ago [1], and my response is to post patches: e.g. https://code.google.com/p/google-web-toolkit/issues/detail?id=6227

I understand that everyone does not have the GWT sources setup to hack on them, so I don't expect patches coming that fast after an issue has been closed, but at one point this is something you'll want to do. I report issues on other projects too, and when possible I try to provide patches (particularly if that's blocking me for my job). I don't expect every patch to come without prior discussion either: if you're not sure how to fix something, ask on the gwt-contrib group and we'll try to help as best as we can.

(and this is in addition to also providing patches for other issues –e.g. https://code.google.com/p/google-web-toolkit/issues/detail?id=8171–, following comments on the issue tracker to help Daniel in triaging issues –the reason I answered on Mauro's issue–, follow the group and stackoverflow, etc. and everything being done mostly during my free time –most issues I reported were for projects at work–)

Put differently: we're all in the same boat!

BTW, I'm with Ed here: there haven't been as many external patches since we moved to Gerrit and started closing issues and asking for patches; and the move to Gerrit really speed up the review process.

[1] https://code.google.com/p/google-web-toolkit/issues/list?can=1&q=status:AssumedStale%20reporter:t.br...@gmail.com&sort=-closed&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars%20Closed

[Mauro Molinari]

Il 04/06/2013 11:11, Thomas Broyer ha scritto:
> 1. the issue tracker has been neglected for years, leading to many

> issues open and never triaged; we need to clean that up

> 2. we can't realistically spend half an hour for each and every of

> these issues: 1500 issues or so would take 750 man×hour, and nobody
> works full-time just on this (that'd be 100 workdays, i.e. 5 months,
> if one person were dedicated full-time verifying issues

> *before* closing them; surely we can spend everyone's time better)
> 3. so as Ray Cromwell says
> <https://plus.google.com/111204862432674062264/posts/A2SDJXAAZJ2>,

> the only viable option is to "crowd source": when in doubt, close

> the issue and see if someone complains, and *then only* spend time
> on that issue.

I'm still convinced that, even if we accept that 3. is the only viable
solution, this way of conducing it (that is, closing bugs without any
explanation) is not so "nice" towards the people who opened the bugs.
Unless you consider it an explanation to force people to look at n
sources of information (two GWT groups, Google+ posts, conference
sessions, web pages, ...) to realize why their reports were "assumed
stale", a simple explanation in the bug reports would have been enough.
This is what I saw in other similar cases (I think of Eclipse TPTP
project, for example, when they decided to put it in "maintenance mode",
but it's just an example).

However I still think that bug reports review and fixing is also a way
to improve a product, so I don't think that 5 months of such an activity
would be wasted time. Unless, again, we think that most bug reports are
invalid... and this sounds to me as a quite debatable assumption.

> tracker. On that specific issue, I could change the status to NotPlanned
> (so it's still closed, but removes the word "stale") but would it change
> anything to the way the issue is handled after that? No. (though if you
> think NotPlanned would be better than AssumedStale, I can make that change).

There's a difference, indeed: the attitude. If you don't care, that's
another story.

Mauro

[David]

Hi,

I asked that many times to my direct managers and even a few levels above. It is indeed in their best interest to also invest in GWT by not producing workarounds but patches.

On that front I am a bit optimistic in my position as well, but it takes time to change that mentality in the corporate world. They like to use (which took them a long time to adapt too as well) but contributing is another big step for smaller companies that are not 100% into software.

David

--

[Spear Timothy]

Mauro,

I am not sure how many open source projects you have been involved with. I did not bother to "google" your name to find out. But I have have seen many projects take the same tactic as the GWT-Dev team did to clean up the issue tracker. I have also seen commercial projects take the exact same approach (Oracle and Microsoft for example). In most cases, they are not even polite enough to use a new term "Assumed Stale" Instead they are marked close and sometimes they may attach a single comment such as "Closed due to lack of activity".

At this point, the project is largely just moving to the concept of "open source" and will have growing pains. (See Eclipse for some examples.)

I am sorry you feel insulted that your issues have not been addressed. However I believe this issue has been beat to death. I know I am tired of seeing emails on it. If you want your issues addressed, check that they do not go against the vision the steering committee created. Then contribute either by providing a fix or paying someone to fix it. Not buy whining about it.
(Personally, due to legal conflicts and other issues I have always paid someone else to provide a fix -- I am normally a consultant and most IP I create belongs to the customer).

Tim

[Thomas Broyer]

On Thursday, June 6, 2013 6:27:57 PM UTC+2, Amir Alavi wrote:

...so what was the answer to this guy's question?

And a follow-up question: Making GWT more maintainable makes perfect sense, so I understand the need to modularize GWT by externalizing several components. But, does that also imply that the Steering Committee as a whole would be effectively washing its hands of any responsibility to externalized components?

In the short term, it's not a question of "externalizing" things, only modularizing so you pick whatever you need in the classpath (the smaller the classpath, the faster the scan done by the DevMode at each refresh, and by the Compiler)

In the middle term, we want to have separate release lifecycles for a few things, so they don't hold the release of "GWT proper".

In the long term, I think the Steering Committee *will* wash its hands of any responsibility to externalized components (just like when deciding to deprecate something). Those components will be completely externalized, with their own maintainer(s) and release lifecycle.

I have the regret to say that one such component is RequestFactory: it looks like I'm the only one dedicated to maintaining it. 

[Jeff Schnitzer]

Hi Thomas. I have two comments that I hope you will find helpful:

 * I think most of the blowback from this could have been prevented with a little more communication. Yes, it's common for big projects to clean out stale bug databases by closing everything and re-opening issues when stakeholders speak up - but it's a good idea to folks know the procedure. Just putting "speak up if you think this issue is still appropriate" in the closing comment would have been enough.

 * It appears that you're using NotPlanned as a "polite" form of WontFix. This is a bad idea because it looks like a priority setting; there is already a Priority tag. WontFix is an appropriate response to issues which are considered to be outside the scope of GWT core, but NotPlanned is being misused for issues which are clearly within the scope of GWT core but simply not prioritized.

For example, consider this issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=3303

This is clearly within the perview of GWT core; it can't be implemented as a plugin, it would bring value to GWT, and there are some nonzero number of people who would like to see it addressed. I totally understand that it is not a priority for the GWT development team... so why not leave it open and deprioritize it?

I fear that using NotPlanned instead of WontFix confuses low-priority issues with "shouldn't be planned" issues. It's very important to maintain a distinction between the two.

Thanks,

Jeff

--

[Daniel Kurka]

Hi Jeff,

we are not leaving issues as open since we want open issues to be a list of stuff we are actually working on. Issues have been left open on the GWT issue tracker for several years now leaving many people unable to find interesting work from the issue tracker.

On the other hand clearly stating that we are not working on something will leave us with less users frustrated who won't feel like we are not addressing issues. We had many open issues that were not addressed in several years and people got angry about this.

Like every project we have to steer our resources into the right direction to make the best product we can possibly make, so there is no way to address every issue. We have to pick our battles.

Me personally I want to have a small amount of issues in PatchesWelcome that external people can work on. (Having different levels of difficulty). I have a clear vision of how our issue tracking should work and I will make a proposal to the GWT steering committee about it once the clean up is finished.

To me cleaning up the issue tracker is Google's job, but maintaining it going forward should be driven by the steering committee. It would just not be fair to handover a bloated tracker for the steering committee to start with. So I put in the effort.

 

We have seen a lot of people stepping up and producing patches for issues they care about, helping those people to pick their battles is very important. 

So if you really like something in GWT that we did not prioritize on you can always provide a patch and we start from there.

Hope this little background helps

Daniel

[Johannes Barop]

Hi,

after reading this thread I have to write that I'm absolutely shocked about the expectations that some here have. It seems that you've forgotten that GWT is an open source project which does not imply that some team is going to implement your wishes for free.

Back to topic:

An issue which has not seen any real contribution for some time should be assumed dead and not clog the other ones. And hey, this doesn't mean that your issue is never being addressed. It means that YOU have to put some work in it. This hasn't to be the ultimate fix but may be some ideas how to fix it or some convincing why it's important.

I had some free time lately where I wanted to work on some random issue. It turned out that it is very hard to find one because all of junk floating around in the tracker.

Cheers,

Johannes

[Mauro Molinari]

Il 09/06/2013 14:48, Johannes Barop ha scritto:
> I had some free time lately where I wanted to work on some random issue.
> It turned out that it is very hard to find one because all of junk
> floating around in the tracker.

I still don't understand (and never will) why old non-fixed bug reports
should be considered "junk". I won't bother to open a new issue again if
this is the case.

Mauro.

[Timothy Spear]

Mauro,

I am going to be slightly cheeky here.

http://www.youtube.com/watch?v=V2f-MZ2HRHQ

At the end of the day. The public issue tracker that was available was not being managed and was largely not maintainable or sustainable in the current form. Google felt an obligation to turn over an issue tracker in a more sustainable and manageable form.

To clean up the issue tracker Google had three basic choices.

1. Invest massive amounts of man power to triage each issue and make determinations themselves. Including fixing/patching or prioritizing. This is not practical from both a resource and a public perception standpoint. If Google puts in the resources, they will not be rewarded because too many people will object to how Google's triage the issues.

2. Start a new issue tracker. This loses all history, and there would be massive screaming and objections.

3. Close everything over a certain age, tell people to submit patches and/or reopen them.

Tim

Mauro.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

[Johannes Barop]

The problem is that you don't know in the beginning which issues are important. Most issues are not even bugs or hard to reproduce because it's so damn outdated.
If I want to hack on GWT I don't want to spend ages in finding relevant issues.

If you find an important bug/issue marked as AssumedStale then talk about it.

[Ed]

Your explanation makes perfect sense.  The folks who submitted patches also have a legitimate claim also and should not take it personally .  But, when there are so many issues, and the transition of the project to the steering committee, it only make sense to start a new bug tracker and not inherit the issues  moving forward from there.  Anyone with outstanding patches  should bring them forward to the new issue tracker if they are still relevant. This shifts the burden of thousands of issues to many more people for investigation rather than the few who can implement the patches.

Just my 2c

ed