RE: [eclipse-pmc] post 3.4.2 builds

[Mike Wilson <Mike_Wilson@xxxxxxxxxx>]

I recognize that our consumers need to get fixes, and I believe that the two maintenance releases we do over the course of the year do a pretty good job of addressing the important ones. But our policy has always been that once 3.x.2 is out the door, we are done with 3.x; people who want fixes post that should take patches themselves, or move to 3.x+1. There are many reasons for this, including:

- We want our consumers to move with us as we go forward. If we keep old streams alive, we make it easier for them to not step up to new versions, which in the short term reduces the amount of testing we get, and in the long term could lead to stagnation for the project.

- After 3.x.2, our focus shifts to development for 3.x+1. Diluting that focus by keeping old streams alive means that we get to do less new stuff. This is bad both because it makes the new release less interesting, and because our developers have to spend more time doing the boring(!) work of backporting.

- We don't ship crap. I'm not sure about the rest of you, but I'm not willing to have a new "release" go out that is "not well tested together". Minimally, if we were going to do this, it would require some level of testing/sanity checks, and that again would dilute the focus. (And that's not talking about the extra burden on rel. eng., and bug triage, and...)

As far as I'm concerned, keeping streams going after the next yearly release is -1.

Of course, there's another side to this, which concerns the kind of commitment companies who ship products on top of Eclipse make to ensure that those products continue to meet the needs of *their* customers, year after year. I fully understand if a company wants to invest in fixing old versions of our plug-ins to support products they've sold. Indeed, IBM puts considerable resources into doing that, and some of those resources come from my team. That doesn't mean that the Eclipse Project should take on the burden of maintaining an n-way union of all fixes that *somebody* needs.

McQ.

Steve Northover---12/03/2009 13:11:06---Let's change "totally untested" (a poor choice of words on my part) to "not well tested together".

From:	Steve Northover/Ottawa/IBM@IBMCA
To:	eclipse-pmc@xxxxxxxxxxx
Date:	12/03/2009 13:11
Subject:	RE: [eclipse-pmc] post 3.4.2 builds

---

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

_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc