I don't think providing variations of
one package helps. In fact, I think it goes against the goal of
the EPP packages to make it easy for people to consume our
software. Of course today they get too much, but slicing and
dicing the packages is not a solution.
With the technologies we have at hand, allowing the features to be
uninstalled is the best we can do. It allows users to get a
glimpse of everything we have and want to push on them, and then
remove the pieces they don't like.
On 01/22/2015 09:55 AM, Chuck Bridgham wrote:
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
