[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT - Ecosystem]
- From: Doug Schaefer <dschaefer@xxxxxxx>
- Date: Wed, 16 Oct 2013 20:42:11 +0000
- Accept-language: en-US, en-CA
- Delivered-to: email@example.com
- Thread-index: AQHOyrAwZCCVcgpKQ0SUTNWvG3apEA==
- Thread-topic: [ide-dev] IDE working group [WAS: Improving Eclipse JDT - Ecosystem]
- User-agent: Microsoft-MacOutlook/220.127.116.11913
Baby steps. We don't even have a WG yet and we're worried about them
changing APIs. I'm pretty sure we can deal with that when it comes up, as
long as the WG doesn't shut out the influencers in our community.
On 2013-10-16 4:26 PM, "Miles Parker" <miles.parker@xxxxxxxxxxx> wrote:
>On 2013-10-16, at 1:04 PM, Konstantin Komissarchik
>>> Incidentally, it was only after joining Tasktop that I became aware --
>>> Steffen had to drill it into my head ;) -- of the major cost/risk
>> associated with
>>> maintenance. When you take a contribution on, you pretty much own it
>> life, so
>>> this is no small thing.
>> That sort of thinking is one of the major obstacles to contributions
>> accepted, which is a far worse problem than occasionally having to pull
>> functionality that has major issues and no one is willing to maintain.
>> Speaking with my plugin developer hat on, I'd rather to see a vibrant
>> Eclipse with lots of activity and a major version every year than one
>> never breaks API, but is stagnating.
>Whether I agree with you philosophically or not, I just don't see that
>changing. I agree that the whole API problem is an enormous albatross,
>but we're not going to fix it by arbitrarily violating API contracts. As
>I say, I think ultimately a deep technical/social change would be needed
>to move away from this basic assumption about stability of API which is
>actually one of the greatest value props the Eclipse ecosystem offers. No
>company is going to adopt or continue to support a platform for which
>existing API can be yanked out from underneath them.
>> - Konstantin
>> -----Original Message-----
>> From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx]
>> Behalf Of Miles Parker
>> Sent: Wednesday, October 16, 2013 12:27 PM
>> To: Discussions about the IDE
>> Subject: Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT -
>>> Am 16.10.2013 um 19:09 schrieb Ian Bull <irbull@xxxxxxxxxxxxxxxxx>:
>>>> I don't believe the problem is 'reviewing' changes, not in the
>> sense. I think the problem is owning the changes once they are
>> 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
>> 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
>> explain to my boss that this should be done on company time, or I need
>> explain to my 6 year old that I can't take her to soccer.
>> Right, I'm familiar w/ that tradeoff. More and more, the children are
>> winning, wrt to personal time on OSS efforts. :)
>> On 2013-10-16, at 11:37 AM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
>>> I'm pretty sure that we'll find a better solution if the contributions
>> comes from work driven by the IDEWG.
>> Yes, that's the most important role that an IDE WG can serve. By
>> potential work, they could provide some sort of seal of approval for
>> But with great power comes.. My concern there is that then things really
>> become an implicit two-tier system -- if your company belongs to the
>> you have a good hope of getting your contributions reviewed, but
>> you're out of luck. OTOH, it couldn't be worse then the present setup,
>> at least individual contributors could look at the IDEWG sanctioned
>> and find a way for their contributions to fit in.
>> The best caseI can think of is usability improvements. If an individual
>> contributor provides a patch that addresses a usability bug that is on
>> the roadmap, how could it possibly be refused. And so perhaps there is
>> least one concrete process improvement here:
>> 1. IDEWG creates roadmap based on member company concerns *in
>> with user community. (Ok, EDP may not be agile, but features should
>> user-driven IMO.) We get some broad themes out of that.
>> 2. Bugs are triaged and mapped to high-level roadmap concerns by project
>> committers in (this should go w/o saying, but can't) consultation w/
>> and contributor community. (Does this enhancement really fit in with
>> x?) 3. Once a bug has been tagged as "road-map", *all* contributions --
>> regardless of source -- should be treated equally wrt to review
>> and acceptance criteria, though maintainability of proposed solution
>> certainly be a factor in acceptance.
>> The basic contract would be *if you work on something that the user
>> community and sponsors agree is important, and you have a high quality
>> contribution, you will have as good a chance as anyone else of getting
>> contribution in*.
>> On 2013-10-16, at 11:48 AM, Konstantin Komissarchik
>> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>>>> 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.
>> Bzzzt! :D That is the one thing that we cannot do, and the source of the
>> Incidentally, it was only after joining Tasktop that I became aware --
>> actually, Steffen had to drill it into my head ;) -- of the major
>> associated with maintenance. When you take a contribution on, you pretty
>> much own it for life, so this is no small thing. I keep thinking about
>> whether there is some kind of deep social coding approach around this,
>> that's for another discussion.
>> ide-dev mailing list
>> ide-dev mailing list
>ide-dev mailing list