Re: [ide-dev] IDE working group [WAS: Improving Eclipse JDT - Ecosystem]

[Miles Parker <miles.parker@xxxxxxxxxxx>]

On 2013-10-16, at 1:04 PM, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> 
>> 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. 
> 
> 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 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 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 -
> Ecosystem]
> 
> 
> 
>> 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.
> 
> 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>
> wrote:
>> 
>> 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 blessing
> potential work, they could provide some sort of seal of approval for work.
> 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 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/ 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.
> 
> cheers,
> 
> Miles
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev