[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-mtj-dev] Fwd: [cross-project-issues-dev] p2 download stats ... again

Hi all,

Reading through this email from Martin, I realized that item 3 needs my attention: I'll fix (version) the download stats ID for Sequoyah, MTJ and Pulsar then. If something goes wrong, I'll revert them the usual way. :)

Another detail is item 4: we should test an update from Helios, not from previous versions. I did not know this, and I thought we all should be aware of it.

Oh, and this should all be painless and smooth: we don't need to rebuild anything in Helios, change build IDs... I will just change one or 2 lines on each of the artifacts.jar/xml... it would be nice to test updates after lunch (my lunch time, 12AM BRT/GMT-3), so we can see new stats available...

---------- Forwarded message ----------
From: Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>
Date: Wed, Jun 9, 2010 at 05:55
Subject: [cross-project-issues-dev] p2 download stats ... again
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


Hi all,
Â
just a couple of things that I learned enabling my download stats - for more details see
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=310132
Â
1. It is better to tie stats to a FEATURE rarther than a bundle. Because bundles come
ÂÂÂ in 2 variants (.pack.gz / .jar) so with a bundle you have duplicate work adding the
ÂÂÂ stats tracker (and, the app from bug 310132 which auto-generates stats properties
ÂÂÂÂdoesn't support it).
Â
1a) Note though that a commercial product which uses a different feature
ÂÂÂ structure than Eclipse Open Source (and so just gets your bundle) won't
ÂÂÂ be counted when you count feature access. That's likely not relevant.
Â
2. If you have a feature and bundle with the same ID, don't add the p2.downloadStats
ÂÂÂproperty to both. Since it would count each download twice.
Â
3. It may be adviseable to version your stats ID somehow. For instance, use
ÂÂÂ "org.eclipse.rse.core_tm320" or "org.eclipse.wst.ui_helios_sr0" or
ÂÂÂ "org.eclipse.ptp_4.0". If you dont' version the stats ID you are tracking,
ÂÂÂ you may run into troubles when we do Helios SR1 which will re-use the
ÂÂÂ same repo location (/releases/helios).
Â
4. Maybe obvious. the stats tracker will not catch people updating from Galileo to
ÂÂÂ Helios. Because the Galileo p2 impl did not have the stats code enabled. You'll
ÂÂÂ only count p2 downloads that happen with Eclipse 3.6.
Â
5. I'm wondering whether the helios aggregator's access to my project
ÂÂÂ repository already counts as a download? Probably not too relevant
ÂÂÂ after all.
Â
So... if I just confused hell out of you, best forget what I just wrote. In the
end, as has been stated before, download stats are only good for trends
and not for absolute numbers anyways. So it's not worth putting too much
effort in.
Â
I'd hope though that some of you found this helpful :)
Â
Thanks,
--
MartinÂOberhuber, Senior Member of Technical Staff, Wind River
direct +43.662.457915.85ÂÂfax +43.662.457915.6
Â

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Thanks again for your patience,

Daniel Pastore