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

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