Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT - Ecosystem]

> Well, maybe his approach is "if it ain't working I just pull it.

That has to be the approach. There is no other way. If no contributor is
interested in fixing issues in a feature that was previously accepted, the
feature must be pulled, even if it was released already and pulling it would
break API or user expectations. If someone objects, they better be willing
to contribute to fixing the issues.

That's far better than fearing to accept features due to perceived support
obligation or letting unstable functionality fester in the codebase.

Of course the "unstable" bar has to be set reasonably high so as not to
catch minor issues that might be ok to live with even if no one is fixing

- Konstantin

-----Original Message-----
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
Behalf Of Gunnar Wagenknecht
Sent: Wednesday, October 16, 2013 11:37 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT -


Thanks for raising those concerns. Few comments inline.

Am 16.10.2013 um 19:09 schrieb Ian Bull <irbull@xxxxxxxxxxxxxxxxx>:
> I don't believe the problem is 'reviewing' changes, not in the technical
sense. I think the problem is owning the changes once they are released. If
I release a patch in p2 that makes its way to Tycho, that produces an
incorrect repo, which causes the release train to grind to a halt -- I'm
responsible for that. Of course the author of the patch was happy to take
credit for the great work, but when push comes to shove in the middle of
February and Luna M5a is broken -- I need to fix it. And I either need to
explain to my boss that this should be done on company time, or I need to
explain to my 6 year old that I can't take her to soccer.

I'm pretty sure that we'll find a better solution if the contributions comes
from work driven by the IDEWG.

> If the original patch was provided by a competing company to better enable
their product, it won't be easy to convince my boss that this is a good use
of my time. The best code review system in the world (read: Gerrit) won't
help here.

I don't think that will be the case for work driven by the IDEWG. I also
don't see this being this case currently in any of the Eclipse IDE related
projects. In theory yes but look at how many patches arrived in Bugzilla
over the years for WTP enhance their support for commercial server
connectors or for Team to allow a better integration with integration XYZ?

> Finally, one of Linus' strengths is his ability to say "NO", this idea is
crap and it's not going in the Kernel. WONTFIX isn't something we do well at

But he also reviews and accepts a lot of crap without being driven by a "I
must support this" fear. Well, maybe his approach is "if it ain't working I
just pull it". :)


Gunnar Wagenknecht

ide-dev mailing list

Back to the top