Re: [cross-project-issues-dev] Retiring the UDC and removing it from the

[Pascal Rapicault <pascal@xxxxxxxxxxxx>]

Before we actually definitely pull the plug on this, I'd like to throw a last minute twist on this and see if the fundamental problems can't be addressed and if what is I suggest would be of interest to anyone. 
As I understood it, the two fundamental pbs are: too much data, data confidentiality. 

IMO all the problems stem from gathering everything about a particular instance (e.g. all the plugins), which in turns generates the confidentiality problem (for example, we can't give out the complete data because it contains the list of all commercial plugins installed by the user), which makes any request to access the data a no-go without signing of your blood and thus render the initiative kinda moot.

What if instead of gathering "everything and nothing in particular" (tm), the UDC became an opt-in mechanism where plug-in authors from eclipse.org could decide to monitor a specific aspect of their plug-ins, thus allowing them to make educated decisions about a particular functionality. For example, for p2, I would like to know how many ppl actually enable the automatic check for updates preference? To achieve this, I would explicitly tell the UDC to gather the value for the known preference key, and later on I could just do a few sql queries against the system to see the results (since the data would have been curated by explicit inclusion, there would not be any confidentiality issue, or at least significantly reduced).
With this sort of opt-in mechanism, the data collected is specific and well-known, thus alleviating the confidentiality issue (for example we would no longer gather the complete list of plugins) and also the size aspect, and consequently making the UDC more consumable by committers since it would allow them to have some sort of eclipse integrated polling system.

Does it make sense? As a committer would you use that?

PaScaL

Ps: Sorry for the late reaction on this topic but it literally came to my mind as I was coming on thinking of the e4 skinning (and don't ask the question I would like to see answered :p).

On 2011-09-20, at 1:04 PM, Wayne Beaton wrote:

> Greetings folks.
> 
> Putting on my Eclipse Foundation staff member hat... those of us at the
> Eclipse Foundation who have been managing the collected data have
> decided that it's time to pull the plug on the UDC server [1]. That is,
> we have decided to stop collecting UDC data. In this regard, we will be
> flipping a bit on the UDC server at the end of September which is cause
> it stop retaining uploaded data. Clients in the field will continue to
> function as though everything is hunky-dory on the server (i.e. they
> should continue to clean up after themselves).
> 
> Changing hats... on behalf of the Eclipse Packaging Project (EPP)--the
> project responsible for the UDC--given that the Eclipse Foundation will
> no longer be collecting usage data, we have decided to pull the UDC from
> the simultaneous release, starting with Juno. By extension, the UDC will
> be removed from all Juno packages.
> 
> The UDC will be included in the Indigo SR-1 and SR-2 releases. I am
> willing to discuss removing the UDC from SR-2 packages if there is
> agreement. The reason for keeping it in the simultaneous release is that
> I am aware of several organizations currently using the UDC as the basis
> for their own collection of usage data.
> 
> The long term status of the project is currently in limbo. There has
> been almost no new development work done on the UDC in a very long time.
> It may be time to archive the code. If anybody is interested in stepping
> up to maintain the code, please express that interest on the epp-dev
> mailing list.
> 
> Thanks,
> 
> Wayne
> 
> [1] http://waynebeaton.wordpress.com/2011/09/16/bye-bye-mon-udc/
> 
> -- 
> Wayne Beaton
> The Eclipse Foundation
> Twitter: @waynebeaton
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev