Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Oomph, Automated Error Reporting, and other changes for EPP Mars M5

Yes, my answer would be the same as the answer from Pascal and from Konstantin. If I had a product on my own, I'd probably build it from scratch instead of relying on an end-user targeted EPP package. Just my opinion. This is easier to manage, more flexible, gives you more control, ...
And in the end there's probably no volunteer out there who would want to do the additional work that would be necessary to create (and to maintain!) such a split-package.

Regards,
Markus



On 22 January 2015 at 18:25, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx> wrote:

> considering these packages as the core building blocks of many products

 

Is this premise valid? Speaking from experience as a package maintainer of third-party packages, by the time you write a script to build a package it’s just as easy (and more flexible) to start with the base platform rather than starting with an EPP package. From what I’ve seen, EPP packages are for the end users

 

- Konstantin

 

 

From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuck Bridgham
Sent: Thursday, January 22, 2015 6:56 AM
To: Eclipse Packaging Project


Subject: Re: [epp-dev] Oomph, Automated Error Reporting, and other changes for EPP Mars M5

 

Thanks for organizing this discussion Markus.

I am evaluating all of these proposed changes, and I would like to expand on some of the ideas expressed in Bug 332989 breaking down the existing packages into features groups (core, package, and extras).
I also desire to include many of the cool features that have enhanced the IDE experience over the years, but in considering these packages as the core building blocks of many products, the decision to grow is not always welcome, even if most of us agree of the validity.   332989 Is trying to address the problem by making it easier to remove non-essential features.  

Have we seriously looked at providing a couple versions of each package?  (I know I'm signing up for more work by proposing this).  

For example the Java EE package started many years ago by providing the classic Eclipse Java + WTP features, but then slowly added Mylyn, eGit, M2e, etc...   We are now considering Code Recommenders, OOmph and possibly more....

We couple provide our packages with these extra services that would make many people happy, but also provide a (Core) package for adopters to consume, and customize.
In the short term, this solution that would make the decision much easier to include additional function, and could also help standardize a set of extra services each package could provide.


Thanks - Chuck

Senior Architect,
WebSphere Developer Tools, Eclipse WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC




From:        Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
To:        Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>
Date:        01/22/2015 05:07 AM
Subject:        Re: [epp-dev] Oomph, Automated Error Reporting, and other changes for EPP Mars M5
Sent by:        epp-dev-bounces@xxxxxxxxxxx





Thanks for your thoughts and your feedback about the update/upgrade/removal of features. I hope that's only the beginning of a longer discussion about the best way to move forward with this.

I share many of your concerns which is why I didn't push on this last summer only a few weeks before the Luna release, but now I feel it's the right time to bring it up for Mars.

Let me try to answer your questions:

- Would “updating a feature individually” break the “simrel testing”? I don't think so, because it is already possible to update an individual feature in a manual way (add p2 repository, select the feature for "installation", p2 will change the install operation into an update operation). The proposed changed wouldn't change the status quo, it would just make it easier and probably more understandable for users. We never defined exact versions in the EPP product definitions (a fact that some may call broken, while others are welcoming this kind of freedom).

- Would users understand that? Based on the feedback users don't understand the current behaviour. My hope is that allowing to update features individually feels more natural to most people.

- What if updates would be pulled in automatically? Yep, that's a risk. On the other hand the user still needs to confirm any updates. If we think that is not enough we need to define exact versions for everything in EPP... it's not really what I'd like to do but it could be a soliution.

- How to chose which feature(s) might get pulled out as root features? Honestly, I don't know. In my initial mail I wrote "all/some" knowing that this is probably the hardest part. Personally I would rule out "all", but if we think a bit further about "some"... then.. who is deciding this? The package maintainer? Should/must it be the same for all packages? I hope to get more feedback and ideas on this, too.

- Roll-back of update operations in p2? Possible. Whenever I tried it (which was not very often) it worked as expected.

I still believe that this would be a major step forward. It's just a question of doing it "right".

(Maybe we should move the discussion to bug 332989.)

Thanks again,
Markus


On 22 January 2015 at 09:19, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Thanks Markus – very interesting, great summary !

 

I’d like to discuss one of the potential changes, you wrote:

 

Ø  Move some/all features of a package from the EPP package feature to the product configuration and make them root features.

 

As far as I understand things, “updating a feature individually” would break the “simrel testing” that constitutes part of the value of the packages.

Would users understand that ? Particularly if updates may be pulled automatically ?

 

I can see how updating some features (like egit) “off-train” can make sense.

But I’d be careful with choosing which feature(s) might get pulled out as root features.

There’s a cost/value decision to make, and the question is how to inform users about possible impact.

 

Also, in case “updating” potentially bears risk of breaking something since the config is untested, it must be super clear how to roll back (just in case).

AFAIK p2 supports this since long, but I never tried it.

Perhaps testing such rollback scenario(s) would need to become part of package testing.

 

Comments / thoughts anyone ?

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On Behalf Of Markus Knauer
Sent:
Tuesday, January 20, 2015 9:47 AM
To:
EPP Developer Mailing List
Subject:
[epp-dev] Oomph, Automated Error Reporting, and other changes for EPP Mars M5

 

Hi Package Maintainers,

today I want to make you aware of some important changes that were discussed on this and other mailing lists and in Bugzilla. I'd like to move forward with all of them in order to get early feedback from you as package maintainers and from our users, and will try to include the required changes in the next Mars M5 milestone in about two weeks.




Bug 457180 - Add Automated Error Reporting to all EPP packages
https://bugs.eclipse.org/bugs/show_bug.cgi?id=457180

Some package maintainers had already decided that the new automated error reporting allows to gain more knowledge about errors that happen in the field, and that it is worth having this feature in their package. Now I think it is time to integrate this in all packages to get even more feedback and error reports.

At the moment this component is developed from the Code Recommenders project team but I hope to move this to EPP in the long run.

 

Gerrit change: https://git.eclipse.org/r/#/c/39423/



Bug 455645 - Integrate Oomph into all EPP packages
https://bugs.eclipse.org/bugs/show_bug.cgi?id=455645

In December I wrote in [2]: "...that was on my wish list for a long time: The addition of Oomph [1] to all EPP packages. It's now a mature project at Eclipse.org and will be part of the Mars Simultaneous Release. My hope is that it will solve many of the problems that we are discussing since many years, e.g. it would ask the user in a wizard for his/her preferred file encoding (UTF-8?) when Eclipse is started for the first time, it can synchronise your preferences between workspaces, it solves the problem with a target definition, ... and a lot more."

I'm using it myself and is another addition to all packages.

 

Gerrit change: https://git.eclipse.org/r/#/c/38613/




Bug 421779 - "Automatically find new updates and notify me" should be enabled in EPP packages
https://bugs.eclipse.org/bugs/show_bug.cgi?id=421779

What we've seen again with last week's SR1a security update: Only a few people are using "check for updates" in Eclipse and by default it is still disabled. To make it easier for us to push updates to our users, we need to make sure that this option is enabled.

 

Gerrit change: https://git.eclipse.org/r/#/c/39539/




Bug 332989 - Allow parts of a package to upgraded or removed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=332989

No Gerrit change (yet), but I'd like to experiment a bit with the RCP/RAP package in the next milestone. If these experiments turn out to be interesting for all packages, we need to come up with a proposal for a structural change. If other packages are interested to experiment with this, please let me know on the bug.


The short description: All packages are using a single EPP package feature that defines the package content, but "check for updates" only searches for updates of this root feature, *not* its child features. As a result of this child features are only updated if and only if there is an update available for the EPP package root feature. The same is true if someone wants to remove a feature. Because all installed features are part of the main dependency chain it is not possible to remove a specific feature.

The proposed solution: Move some/all features of a package from the EPP package feature to the product configuration and make them root features.

 

Thanks and regards,
Markus


[1] http://dev.eclipse.org/mhonarc/lists/epp-dev/msg03233.html
[2] http://dev.eclipse.org/mhonarc/lists/epp-dev/msg03319.html

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev


_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



Back to the top