Community
Participate
Working Groups
I think this applies to all (even service releases), but especially off-schedule ones, such as the "security update" we did in January. For evidence that "users notice", see http://jdevelopment.nl/mysterious-44120150109-eclipse-luna-update-sr1a/
Describe where? The website? In the product/feature description?
(In reply to Wayne Beaton from comment #1) > Describe where? > > The website? > > In the product/feature description? The product/feature description. The goal is when someone "suddenly gets offered an unexpected update", they can read the "description box" in p2 UI and at least get an idea of what it's for or what its about. I believe they are currently always "blank".
Yes, the description of the product IU is currently empty, only the features contain a short description. What about adding some generic package information into this field and point everyone to a dedicated web page where we can list the changes for every version? That would minimize the effort that is required to update all product definitions all the time.
(In reply to Markus Knauer from comment #3) > Yes, the description of the product IU is currently empty, only the features > contain a short description. > > What about adding some generic package information into this field and point > everyone to a dedicated web page where we can list the changes for every > version? That would minimize the effort that is required to update all > product definitions all the time. That may be overkill. A URL, if possible, is always nice. But normally, I was thinking it's just say "The Mars release" or The Mars SR1 release" (which, I'd think could be automated). The sense I got from the blog post was the person wanted to make sure it wasn't some kind of "scam" or "trash" he was about to be updated to ... so, that's the time its more important to say something like "A update to the Luna SR1 release that fixes JGit security issue (xxx) See bug YYY." Or, something like that. I'll admit, I have not thought through the "continuous release" scenarios that some talk about. Some products give a detailed "list of bugs fixed" (even if in URL) and others just say "numerous bug fixes" or something vague. I guess "Wayne is right" (even though he just asked questions :) that we probably should have updated https://www.eclipse.org/luna/ and mentioned something there.
(In reply to David Williams from comment #2) > The product/feature description. I believe that Bug 361033 needs to be solved before we can provide a product description.
(In reply to Wayne Beaton from comment #5) > (In reply to David Williams from comment #2) > > The product/feature description. > > I believe that Bug 361033 needs to be solved before we can provide a product > description. My *guess* is we could solve it with a little p2.inf magic. And fair to say ... "ok, show us" :) I've often wondered by *our* products didn't have a description but was not aware of bug 361033. Thanks!
I think the examples I provide in bug 458896 can also be used in EPP. They are not a "complete, ideal" fix, but covers the "basic cases". (I'd like to think solving 80% of the problem is enough ... but ... up to EPP if you'd like to follow suit.)
While not fully automated yet, I added the proposed properties to the p2 metadata of all EPP products for Neon M6. After M6 I'd like to use the same search&replace that we are using in other places to update the version string (which is the reason for leaving the bug open).
The EPP project does not have its "own" Packager anymore. EPP uses other technologies, such as Eclipse Tycho, Maven and Eclipse PDE. Therefore any remaining bugs are now being closed as WONTFIX. If this bug is still relevant, please make a comment and we'll move it to the correct project/component for further investigation. This change was made as part of a bulk change.
