[
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.
>
> 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.
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.
- 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
