Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] IDE working group questions

Yes, add BlackBerry/QNX Momentics to that list. We have a couple of really
nice usability improvements to the ToolBar and New Project Wizard. We'd
like to push those upstream once we generalize them, but we need a forum
where we can reach all the other IDE builders out there and work together
on it.

Mind you that was the intention of this mailing list. I see the working
group more as a way for members who don't have human resources available
to contribute in other ways (like cash to hire full time contributors).

Doug.

On 2013-10-24 9:00 AM, "Max Rydahl Andersen" <manderse@xxxxxxxxxx> wrote:

>I agree I don't want to see a monolithic IDE, but I would like to see a
>place
>where focus areas like usability, performance and keeping the IDE modern
>are in
>focus.
>
>I feel most of platform works very much in isolation and only reacts (and
>rightfully so)
>when enough have pointed out the same issue enough times.
>
>I feel creating a working group which could have as goal to at least
>improve one or two key
>aspects for the release train based on experience from the many eclipse
>based IDE's out there
>would be an interesting approach.
>
>From talking with guys from SpringSource, IBM, Oracle etc. we all seem to
>solve the same
>issues but never realize we both did it because we don't really have a
>forum to discuss or
>affect the "Eclipse IDE" in concert.
>
>/max
>
>On Mon, Oct 21, 2013 at 11:58:17AM -0700, Konstantin Komissarchik wrote:
>>I don't think we need another container project or a monolithic "IDE"
>>project to hold features that don't find place in existing projects.
>>These
>>days, it is a lot easier to create a micro-project under say Tools or
>>Technology than it used to be. It isn't a matter of a few clicks, like it
>>should be, but it is a lot better than what it used to be and you meet a
>>lot
>>less resistance along the way.
>>
>>
>>
>>I am personally of the opinion that it isn't good to keep growing the
>>size
>>of the platform. The platform should stay small to be suitable to a wide
>>variety of usecases and be mainly concerned with facilitating work
>>happening
>>elsewhere. We do not need to stuff more into the platform to improve
>>Eclipse
>>IDE.
>>
>>
>>
>>- Konstantin
>>
>>
>>
>>
>>
>>From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
>>Behalf Of Doug Schaefer
>>Sent: Monday, October 21, 2013 11:41 AM
>>To: Discussions about the IDE
>>Subject: Re: [ide-dev] IDE working group questions
>>
>>
>>
>>Maybe this is a case where the Eclipse IDE Project makes sense. Then we
>>wouldn't be having this discussion and the Eclipse IDE would have it's
>>image
>>viewer. Mind you, we still might need changes to the Platform to enable
>>it,
>>but they would be in the right direction of making the Platform more
>>pluggable.
>>
>>
>>
>>BTW, we have a lot of functionality in the CDT that really belongs in the
>>Platform, In Our Humble Opinion. We just found it easier (back in the
>>dark
>>times), to just implement it close to home. I wonder how many other
>>projects
>>have done the same. I'd bet we could build up an IDE project with a lot
>>of
>>functionality day one.
>>
>>
>>
>>But I'd like to hear from Platform leadership team first. Does the
>>Platform
>>want to open up more in this direction? Or would they prefer we find a
>>different home for these common features.
>>
>>
>>
>>Doug.
>>
>>
>>
>>From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
>>Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
>>Date: Monday, 21 October, 2013 2:20 PM
>>To: 'Discussions about the IDE' <ide-dev@xxxxxxxxxxx>
>>Subject: Re: [ide-dev] IDE working group questions
>>
>>
>>
>>Having been involved in the discussion and having made several attempts
>>to
>>facilitate a solution, I see the image viewer story as most illustrative
>>of
>>what happens when a contributor is unwilling to be flexible. Various
>>options
>>were offered that would have led to an image view in Eclipse IDE
>>packages,
>>but it was either in platform or nowhere, so in the end we have no image
>>viewer in Eclipse IDE to date.
>>
>>
>>
>>Projects will reject features for various reasons. We need to be ready to
>>find alternate accommodations and contributors need to be flexible
>>enough to
>>work with such accommodations. We are certainly better prepared for this
>>today than six years ago. EMO is more willing than before to accept
>>micro-projects and improvements in common infrastructure (such as the
>>common
>>build system) make it a lot less costly to have a project around a single
>>feature, if such thing is necessary.
>>
>>
>>
>>- Konstantin
>>
>>
>>
>>
>>
>>From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
>>Behalf Of Doug Schaefer
>>Sent: Monday, October 21, 2013 10:55 AM
>>To: Discussions about the IDE
>>Subject: Re: [ide-dev] IDE working group questions
>>
>>
>>
>>BTW, to be fair fair about the image viewer story, the rejection
>>happened 6
>>years ago near the end of the dark times.
>>
>>
>>
>>From: Eugene Ostroukhov <eostroukhov@xxxxxxxxxx>
>>Reply-To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
>>Date: Monday, 21 October, 2013 1:39 PM
>>To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
>>Subject: Re: [ide-dev] IDE working group questions
>>
>>
>>
>>I do not make purchasing/consortium participation decisions on behalf of
>>NVIDIA. I am an input to such decisions made by my superiors.
>>
>>
>>
>>What I am writing to this list is my personal opinion.
>>
>>
>>
>>At NVIDIA, I am working on "Nsight Eclipse Edition" - that is an
>>Eclipse-based IDE for CUDA developers. Before NVIDIA I was working on
>>other
>>Eclipse-based IDEs (paid or not).
>>
>>
>>
>>I find it ironic that it is possible to get GSoC student work on adding
>>generics to the JFace into the main repo, while experienced developer's
>>contribution of image viewer (I mentioned the bug number in my original
>>letter) was rejected with prejudice. I personally had to implement
>>similar
>>viewer more then once for different projects.
>>
>>
>>
>>I am looking at this WG from a point of view "what would we get for
>>participation" - as this is the question I need to answer if I raise this
>>topic with my manager.
>>
>>
>>
>>Personally, I believe there is a need for a more open collaboration place
>>for adopters to work on what they see as a better Eclipse Platform for
>>IDEs.
>>Currently adopters are forced to ship their own forks - so I wonder if
>>this
>>project could become some sort of unified fork that better suits the
>>needs
>>of IDEs.
>>
>>
>>
>>One thing I would like to point out is that for some teams it might be
>>easier to contribute developer time than money as those decisions are
>>made
>>on different levels and development teams more readily recognize the
>>value
>>of collaboration.
>>
>>
>>
>>Best regards,
>>
>>Eugene
>>
>>
>>
>>On Oct 21, 2013, at 9:24 AM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>
>>wrote:
>>
>>
>>
>>
>>
>>
>>Before playing this back-and-forth:
>>
>>
>>
>>What's your position on the WG - or funding developers in general that
>>work
>>on, say, JDT, CDT or EMF? Are you looking at this from an investors view
>>point or more from a developer's view point. Not sure what the role of a
>>lead architect at nvidia is.
>>
>>
>>
>>In any case, from your writing I get the impression that you don't see
>>any
>>good way to contribute to the existing platform (no critic in here). If
>>that's true, what can we do? Will all tries to modernize the Eclipse IDE
>>fail?
>>
>>
>>
>>Marcel
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>Am 21.10.2013 um 17:54 schrieb Eugene Ostroukhov
>><eostroukhov@xxxxxxxxxx>:
>>
>>
>>
>>
>>
>>
>>Gunnar,
>>
>>Replies inline.
>>
>>
>>
>>So let's imagine some company is really bothered by such issues and joins
>>this working group (note the hefty price tag of $120k/year).
>>
>>
>>
>>The price tags are just a proposal and haven't been validated currently.
>>But
>>I think you are referring to the highest one which includes steering
>>committee membership.
>>
>>
>>
>>My understanding is that non-steering participation does not give any
>>voting
>>rights.
>>
>>
>>
>>
>>
>>
>>1. Are there any guarantees somebody would actually implement these
>>enhancements? What may prevent these funds from being spent on EMF
>>enhancements if they get more votes?
>>
>>
>>
>>I think it will be important to make that the working group operates open
>>and transparent. Therefore, the whole funding and wishlist including
>>voting
>>will be visible. That allows to make a clear judgment on what impact
>>specific funding will make.
>>
>>
>>
>>This means that either companies invested in CDT or EMF will not get what
>>they joined for.
>>
>>
>>
>>
>>
>>
>>2. What would be a timeframe before implementation starts? Would there
>>be a
>>committed delivery schedule?
>>
>>
>>
>>I expect this to happen as part of the work item analysis and upon
>>assignment of such items to the implementation partner.
>>
>>
>>
>>How will this happen? A lot of time will be spent defining the "wish
>>list",
>>then RFPs will be sent out, prospecting "implementation partners" will
>>submit proposals, voting on proposals will commence, so on? Sounds like
>>years will pass without any output.
>>
>>
>>
>>
>>
>>
>>3. How could such a general-purpose text editor avoid sharing the fate of
>>Bug <https://bugs.eclipse.org/bugs/show_bug.cgi?id=155323>  155323?
>>
>>
>>
>>It's an important role of the working group steering committee to find
>>solutions to such problems. I could imagine that if no project is
>>willing to
>>accept a feature such as a general purpose image viewer or text file
>>editor,
>>the work is brought in as a new project and made available as part of the
>>release train and in the downloadable packages.
>>
>>
>>
>>I do not think these two items can happen without at least some platform
>>changes (I am only familiar with E3 - and at least hooks will have to be
>>put
>>there).
>>
>>
>>
>>Best regards,
>>
>>Eugene
>>
>>  _____
>>
>>This email message is for the sole use of the intended recipient(s) and
>>may
>>contain confidential information.  Any unauthorized review, use,
>>disclosure
>>or distribution is prohibited.  If you are not the intended recipient,
>>please contact the sender by reply email and destroy all copies of the
>>original message.
>>
>>  _____
>>
>>_______________________________________________
>>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
>>
>>
>>
>
>>_______________________________________________
>>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



Back to the top