If it’s of any help, I can provide a summary of all UI freezes with their average duration based on the incoming error reports. It will take me a day to get the aggregation and deduplication for UI freezes right (it’s not that great at the moment) but if it would be used for identifying potential candidates it might be worth doing it.
That’s not solving annoying startup problems but I can imagine that UI freezes are (in general) easier to fix since they are already located and don’t need such a deep analysis.
We also have problems that were reported by 100+ users. Those may be good candidates as well.
I want to push forward with both the Great Fix and the Hackathon for
EclipseCon.
For the Great Fix, I recommend that we target doing one per quarter
between now and Neon. We can determine where to take it after that.
I would like to focus on bugs that improve the IDE experience, which
IMHO includes performance. Alternatively, we can maybe pick a focus
for each round (e.g. UX in 2015Q3, Performance in 2015Q4, ...).
I've already started the process of sorting out prizes: I may be
able to swing the equivalent of a tablet/quarter for the grand prize
and then t-shirts or other swag for runners up. I'm open to
suggestions.
Thoughts?
Wayne
On 14/07/15 06:34 PM, Pascal Rapicault
wrote:
I second Wayne in thinking that
performance problems are not good candidates for a competition,
at least not until we have discrete problems identified.
Historically, impacting changes in the realm of performance have
been done after long investigations carried out by a team
created specifically for that purpose (usually composed of
people from various projects).
At this point, I think we should first understand the exact
scenarios we care about (which epp pack, content of the
workspace, plug-ins installed, etc) and go from there. So if
there is any help to be obtained from the community it is in
collecting the scenarios that are slow.
Pascal
On 07/14/2015 10:18 PM, Lars Vogel wrote:
Thanks Wayne for the clarification. The "I disagree." did put me
on the wrong track for the rest of your reply. ;-)
Dani, could
someone from your team help with a reasonable startup
measurement test?
Structure-wise,
I like the Great-fix organization. Having 3 iterations and
having three picks of winners would be great IMHO.
As the task is relatively complex, I think the incentive
should be more than a T-Shirt, Tablets would again be great
IMHO or a price money from the foundation. Not sure what the
new structure is, but sponsoring this with the new money
initiative might be an opportunity to motivate skilled
developers.
If the Eclipse IDE starts significantly faster than other
IDEs this would be big plus for our IDE.
Best regards, Lars
On Tue, Jul 14, 2015 at 10:08 PM,
Wayne Beaton <wayne@xxxxxxxxxxx>
wrote:
Re-read my earlier
response.
Having said that, I think that having another Great Fix competition is a
great idea and I'd like to have AC involvement in the decision making
process. I'll see if I can sort out some prizes that are better than
t-shirts. When do we do this and how is it structured?
Wayne
On 14/07/15 02:57 PM, Lars Vogel wrote:
Wayne, as the hackathon idea seem not to have a lot of consent (by
Dani, Ed and me), what about the original proposal of having a contest
similar to the Greatfix with prices for the largest improvement?
Best regards, Lars
On Mon, Jul 13, 2015 at 7:11 PM, Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
Performance work is always challenging and most of it is necessarily
focused on measurements. I can't imagine significant performance
improvements resulting from anything other than a primary focus on
measurements. A hackathon doesn't seem the place for doing such work.
+1
Dani
From: Ed Merks <ed.merks@xxxxxxxxx>
To: eclipse.org-architecture-council@xxxxxxxxxxx
Date: 13.07.2015 18:49
Subject: Re: [eclipse.org-architecture-council] Competition for
improving the IDE startup time
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
________________________________
Performance work is always challenging and most of it is necessarily focused
on measurements. I can't imagine significant performance improvements
resulting from anything other than a primary focus on measurements. A
hackathon doesn't seem the place for doing such work.
On 13/07/2015 6:09 PM, Lars Vogel wrote:
Hi Wayne,
Sounds like you thinking of your idea of an extended hackathon during the
confrrence. This might work if you get the correct parties together for a
longer time.
For me personally EclipseCon is usually a very busy time, not sure if an
extended hackathon will work for the other IDE developer. The stuff I have
seems fine during hackathons are usually trivial fixes and cleanup work.
Best regards, Lars
Am 13.07.2015 5:34 nachm. schrieb "Wayne Beaton" <wayne@xxxxxxxxxxx>:
I disagree. This sounds like a complex problem with lots of moving parts. I
envision a "hackathon" goal of improving start up performance in certain
scenarios by some target.
I completely forgot to bring this up on the last call, but I'd like to get
the AC to recognize a regular "contributor of the month". I'm thinking that
we make this a regular part of every call to spend ten minutes (maximum)
nominating, discussing, and voting on great contributions for the month. The
winner gets highlighted in a blog post (and maybe the newsletter), and gets
a t-shirt. I'll have to work on better prizes.
Having said that, I think that having another Great Fix competition is a
great idea and I'd like to have AC involvement in the decision making
process. I'll see if I can sort out some prizes that are better than
t-shirts. When do we do this and how is it structured?
Wayne
On 13/07/15 11:03 AM, Lars Vogel wrote:
Hi Wayne,
I think it is not a good candidate for a hackathon, IMHO a community
approach like "Greatfix" would work better here.
Best regards, Lars
On Mon, Jul 13, 2015 at 4:53 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
Is this a potential candidate as a "hard problem" that committers can work
on together in the Hackathon at EclipseCon Europe?
Are there any existing bugs that we can use as "bugday" targets for
contributors at the Hackathon?
Wayne
On 13/07/15 02:14 AM, Lars Vogel wrote:
Hi,
In the last release we had the Great bug initiative.
I think one great area for improvement would be the reduction of the startup
time in the IDE.
Maybe the Eclipse foundation could make a competition for improving it?
Accepted contributions could be ranked by improvement and the largest
improvements would win the price.
For the measurement we have in platform a startup time test, which I think
could be used for the measurement. Dani, what do you think?
If we would do this, we should get the buy-in from the involved projects.
For platform Dani would have to say yes, for p2 Pascal, etc.
Best regards, Lars
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web:
http://www.vogella.com
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
[attachment "att3juyu.png" deleted by Daniel Megert/Zurich/IBM] [attachment
"attyyevs.png" deleted by Daniel Megert/Zurich/IBM]
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
IMPORTANT: Membership in this list is generated by
processes internal to the Eclipse Foundation. To be
permanently removed from this list, you must contact emo@xxxxxxxxxxx
to request removal.
--
Eclipse Platform UI and e4
project co-lead
CEO vogella GmbH
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.