[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-pmc] post 3.4.2 builds
|
Hi there,
regarding "completely untested": Community clients want the
fix, perhaps even contribute the fix, so I'd expect that they
also test the fix? In the case of post-3.4.2 builds I'd see the Eclipse project
not so much as a "product" providing well-tested ready consumable stuff. In my
opinion, the Eclipse Project would be providing infrastructure (in the form of
running scheduled builds and an update site).
The important point is that Client X who adopts a given fix
at a given moment in time doesn't get broken by client Y later. In this sense,
any "Check for updates" functionality may be problematic, since those clients
really want to deploy what they have tested only. Perhaps it would be better in
this case to not even provide an update site, but provide downloadable artifacts
only (i.e. an M-build containing the standard ZIPs as well as a zipped Repo for
those who consume p2 in their build scripts).
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Good points.
Re #0, "completely untested" feels like a bit of an
overstatement. One advantage of doing a full build is that we can get a
full automated test pass. That's more testing than what we get if you or
I just rebuild our plugin and put it up on a web page
somewhere.
Re #1, yes, that's the tradeoff and it's hard to say
which is right. As an example, MSFT releases their hotfixes as
individual patches, individually installable and uninstallable; I assume
that's because of customer pressure. So indeed maybe having a single
update site is not the right thing.
Re #2, I think this is already the situation.
Third-party products are already based on post-..2 releases (I know IBM does
this, and BEA did too). Even between service releases people patch
specific plugins. Product name and release train has never been a
reliable indicator of plug-in version.
I do think the releng resources are a very significant
issue though, not to be glossed over. On the other hand, if we don't do
it as an automated joint build, someone's gonna have to teach me how to sign
packages and make an update site, and that might be even harder
:-)
Thanks,
-walter
For me, the build would
contain fixes that product teams from different companies and different
developers felt were needed for a 3.4.3 build (if there was one, but there
wasn't). It would be totally untested. That's bad but we could
say this up front.
1) Consumers
of the build would need to be ok with this and I suspect that they would
not. For example, you care about one small bug in JDT but you risk a
bunch of unrelated code from SWT that could break your product
completely.
2) What people were
running in the field would depend on when the build was made. How
could bugs be reported against it or when something breaks, how can we know
what the person is actually running?
