RE: [eclipse-pmc] post 3.4.2 builds

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Let's change "totally untested"
(a poor choice of words on my part) to "not well tested together".

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

03/12/2009 06:39 AM

Please respond to
eclipse-pmc@xxxxxxxxxxx

To	<eclipse-pmc@xxxxxxxxxxx>
cc
Subject	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
http://www.eclipse.org/dsdp/tm

---

From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of Walter Harley
Sent: Donnerstag, 12. März 2009 02:04
To: eclipse-pmc@xxxxxxxxxxx
Subject: RE: [eclipse-pmc] post 3.4.2 builds

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

---

From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of Steve Northover
Sent: Wednesday, March 11, 2009 3:55 PM
To: eclipse-pmc@xxxxxxxxxxx
Subject: Re: [eclipse-pmc] post 3.4.2 builds


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?
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc