On 07/16/2013 08:43 PM, Pascal Rapicault wrote:
The fact that all the bundles composing packages are included in the
release repo and that the ius for the epp are also there.
Ok. I thought that EPP was only a consumer of the release train and that
those flavours of the IDE could be built anytime
The fact that all the bundles composing packages are included in the release
repo and that the ius for the epp are also there.
On 2013-07-16, at 8:25 PM, Mickael Istria wrote:
> On 07/16/2013 08:20 PM, Ian Skerrett wrote:
>> The download page is driven by the output of the EPP project which b
On 07/16/2013 08:20 PM, Ian Skerrett wrote:
The download page is driven by the output of the EPP project which
builds the packages from the release train repo. A lot of this is
automated so I would suggest any change to the release cycle will also
need to include how we update this workflow.
The download page is driven by the output of the EPP project which builds
the packages from the release train repo. A lot of this is automated so I
would suggest any change to the release cycle will also need to include how
we update this workflow.
Ian
From: cross-project-issues-dev-boun
+1 We're going to run into this with CDT. We will want to update the package
every 6 months as well.
From: Greg Watson mailto:g.wat...@computer.org>>
Reply-To: Cross project issues
mailto:cross-project-issues-dev@eclipse.org>>
Date: Tuesday, 16 July, 2013 4:13 PM
To: Cross project issues
mailto
That's what started this discussion. The user shouldn't have to do anything to
get the fix. It should just work. Which led us to the desire to override the
defaults where we disagree with the settings the projects put in.
Doug.
From: Daniel Megert mailto:daniel_meg...@ch.ibm.com>>
Reply-To: Cro
While I support more frequent release cycles (PTP release more frequently so it
would suit us well), I'd like to also suggest that projects also have more
control over the packages available on the download site. In particular, we'd
like to be able to update our package with a new build when we
Christian,
the "refresh" issue has been resolved a year ago in the Juno (4.2)
release, but you might not see it in old workspaces yet. Make sure the
General > Workspace > 'Refresh on access' preference is checked. You can
even go further and enable 'Refresh using native hooks or poling'.
Regar
Sharing prefs between workspaces sounds good. The suggested solution still
sounds a little bit too complicated (for my taste of course). If I open a
workspace, why cant I not directly reference an existing workspace and copy the
preferences from there ? (why the extra export step) And for comple
I think Eclipse can offer a feature to synchronize kinds of configuration,
like Chrome and Firefox Sync.
Developers can use their account of eclipse.org to synchronize their
installation of plug-ins, preference configuration and even more.
Kane
On Tue, Jul 16, 2013 at 3:26 PM, Daniel Megert wr
[Cc'ing to recommenders-dev]
Wayne Beaton wrote:
> It's an interesting thought.
>
> But it sounds a lot like the Usage Data Collector (UDC). Unfortunately,
> we didn't collect this sort of information and the UDC has been shut down.
>
> Any time you "call home", you're going to make somebody ang
We can definitely do better as mentioned in several comments already. Just
wanted to mention ? though not very user-friendly ? there is a mechanism
that allows to set most preferences (those that appear in the preference
dialog) per install(s):
eclipse[c].exe -pluginCustomization
where the
12 matches
Mail list logo
