[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT - Ecosystem]
- From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
- Date: Wed, 16 Oct 2013 13:51:20 -0700
- Delivered-to: firstname.lastname@example.org
- Thread-index: Ac7KriCTe1uyLLSyQ7iNHjf+h4FMrwAAIUTg
> Whether I agree with you philosophically or not, I just don't see that
It will have to change. I just don't see any other way to improve
contribution review logjam.
> No company is going to adopt or continue to support a platform for which
> existing API can be yanked out from underneath them.
That's an exaggeration. The reality is more complicated. Clearly, if
everything changes with every release, no one is going to be interested in
adopting Eclipse. However, if occasionally API is broken for a good reason
(such as no one is willing to support a feature any longer), the overall
value still far exceeds the work required to keep up, so I would not
anticipate a drop in adoption.
It's a balance, but if the new release brings more value than the cost of
migration, adopters are not going to mind paying the price. I am seeing that
first-hand with Sapphire. Outside of service releases, every single release
breaks API extensively in order to move forward. We are on the seventh major
release now and I have not seen a single complaint from adopters regarding
migration. Sometimes there is a question on the forum to clarify something
that wasn't fully covered in the migration guide, but that's it. Further, I
rarely see questions on forum or bug reports on old releases, indicating
that existing adopters are tracking latest releases rather quickly. Far from
loosing adopter base, the community around the project is growing at a
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
Behalf Of Miles Parker
Sent: Wednesday, October 16, 2013 1:27 PM
To: Discussions about the IDE
Subject: Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT -
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
> being accepted, which is a far worse problem than occasionally having
> to pull functionality that has major issues and no one is willing to
> 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
> that 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]
> On 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
> 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.
> 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
>> I'm pretty sure that we'll find a better solution if the
> comes from work driven by the IDEWG.
> Yes, that's the most important role that an IDE WG can serve. By
> blessing potential work, they could provide some sort of seal of approval
> 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 IDEWG you have a good hope of getting your contributions
> reviewed, but otherwise, you're out of luck. OTOH, it couldn't be
> worse then the present setup, and at least individual contributors
> could look at the IDEWG sanctioned road map 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 the roadmap, how could it possibly be refused. And so
> perhaps there is at least one concrete process improvement here:
> 1. IDEWG creates roadmap based on member company concerns *in
> consultation* with user community. (Ok, EDP may not be agile, but
> features should still be user-driven IMO.) We get some broad themes out of
> 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/ user and contributor community. (Does this enhancement
> really fit in with theme
> x?) 3. Once a bug has been tagged as "road-map", *all* contributions
> -- regardless of source -- should be treated equally wrt to review
> involvement and acceptance criteria, though maintainability of
> proposed solution could 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
> that 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 conundrum.
> Incidentally, it was only after joining Tasktop that I became aware --
> actually, 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 for life, so this is no small thing. I keep
> thinking about whether there is some kind of deep social coding
> approach around this, but that's for another discussion.
> ide-dev mailing list
> ide-dev mailing list
ide-dev mailing list