Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Re: [ecf-dev] ECF for Platform 3.4.2
Ok, I break things down below but the summary is that the only substantive difference (other than javadoc.xml) between our Release_2_0 stream and Release_2_1 stream is the version number in the manifest (i.e. 2.0.1 and 2.1.0).
I discovered something else, however, and that's that the platform release 3.4.1 didn't use new ECF plugins for 3.4.1 (i.e. it just reused the 6.11.2008 version), so even with the Release_2_0 branch there are some critical bug fixes (i.e. since last June) that haven't been previously deployed. Obviously I would like some additional smoke testing of these (I've run all our tests repeated just fine, and will rerun them...but the main issues we seem to have experienced have more to do with proxies, misbehaving servers, JRE bug, 'in the wild', etc).
So, the upshot is that it doesn't matter to me whether we use Release_2_0 stream or Release_2_1 stream (as they are the same modulo version numbers), so we'll use the Release_2_0 stream (with appropriate 2.0.X version number to make everyone happy).
But it would be prudent to have *some* additional testing of the fixes described below if at all possible. One thing to note...the integration builds (for Eclipse 3.5/3.0 were using these fixes up until we moved to using httpclient, so this does provide some degree of additional testing).
But I would like to know...when/how are we doing these 3.4.2 builds? Are there any scheduled 3.4.2 integration builds before the actual release? 

Thanks,

Scott

Changes from 6.11.2008.1715

org.eclipse.ecf
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256580

org.eclipse.ecf.filetransfer
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248485

org.eclipse.ecf.provider.filetransfer
https://bugs.eclipse.org/bugs/show_bug.cgi?id=235933
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244775
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247197 (workaround for apparent JRE socket problem by setting Connection: close header) 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=249990


Scott Lewis wrote:

Hi Jeff, Thomas, etc.,
I'm getting a low down on exactly the changes applied in these six plugins between June/Ganymede and today (on our Release_2_1 branch). My belief is that only the bugs identified/submitted by p2 were actually committed to the Release_2_1 stream, but I'll verify that. I don't remember whether they were actually identified as critical or not, but they were treated that way. 

So I'll send another posting with details in a little while.
Just so it's clear...this is mostly about us (ECF team) not having the resources to maintain several build streams simultaneously in our automated build...i.e. 2.0, 2.1, 3.0...crossed with builds for p2/platform, and builds for ourselves (since we can't distribute our own versions of these six bundles). So although of course we *can* do a platform integration build using the 2.0 stream (with some work and time), we've not been maintaining it for several months because we've had to be concerned with our 2.1 release (Dec 24) and 3.0 development streams. 

Scott

Jeff McAffer wrote:
I agree with you on all counts. There's no doubt that the newer ECF is general goodness. The question is what issues those fixes might introduce (for example). Without reasonable testing, it is hard to say. For 3.4.2 we should only be looking at known, targeted, critical issues. So the key question goes to the p2 team, is there something that meets these criteria that the new ECF fixes? We should get that motivation first and then look further at how to consume the identified fixes. 

Jeff

Thomas Watson wrote:
I am not nearly as close to ECF or even p2 as others on this list. But I have to say that introducing new ECF versions (of the 6 bundles used by p2) into the Eclipse SDK for 3.4.2 raises a number of red flags.
1) From the Eclipse PMC point of view I believe they have pretty much shutdown development of 3.4.2. They need PMC approvals for all fixes from now on. 2) Equinox is under the RT PMC so we can make our own decisions about what p2 includes in the 3.4.2 release, but I think we should model closely the Eclipse PMC with respect to ramping down of 3.4.2. 3) Unless I am mistaken, very little testing has been done using 3.4.x p2 with the ECF Release_2.1 branch bundles. I don't see how this can be considered a low risk effort for a point release this late in the 3.4.2 cycle.
I'm not saying I cannot be convinced otherwise, but I fear that we may introduce subtle bugs and regression. If this is done we must have adequate testing to convince ourselves that no regressions will be introduced as a result. 

Jeff, what are your opinions on this?

Tom
Inactive hide details for Scott Lewis ---12/29/2008 11:33:31 PM---Hi Jeff,Scott Lewis ---12/29/2008 11:33:31 PM---Hi Jeff,
From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 12/29/2008 11:33 PM
Subject: Re: [p2-dev] Re: [ecf-dev] ECF for Platform 3.4.2
------------------------------------------------------------------------ 



Hi Jeff,

Jeff McAffer wrote:
> where did we finish up on this?

I'm not sure.  I'm having a little problem with posting to ecf-dev, so
that's causing a little bit of churn with me right now, but that's
beside this point.

I would like to build the ECF contribution for 3.4.2 from the ECF
Release_2.1 branch.  The changes to the relevant plugins (6 I believe)
have been almost exclusively in response to bug reports...and we have
been/are saving our API additions/changes for ECF 3.0 (Galileo). Further, this contribution will *not* include httpclient-based (although it's debatable whether perhaps it should due to the apparent JRE-induced 
crashing bug some p2 clients were experiencing).

So as long as this is OK (using ECF Release_2_1 branch for our
contribution to 3.4.2 platform build) we need to figure out/do
mechanics...e.g.

a) When does this contribution have to be ready for consumption by
platform build (for integration and/or release builds)?
b) How will the contribution be made (e.g. via bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499  ...perhaps in a
special location to make distinct from HEAD-based integration build)

Thanks,

Scott

>
> Scott Lewis wrote:
>> Hi Thomas,
>>
>> Thomas Watson wrote:
>>>
>>> Scott,
>>>
>>> What version of ECF are you planning to contribute to the point
>>> release of Ganymede? I don't think we should upgrade the ECF bundles 
>>> included in the SDK to something that will be a higher version than
>>> what ECF contributes to the point release of Ganymede. Otherwise
>>> wouldn't we risk introducing compatibility issues for the other ECF
>>> bundles delivered in Ganymede?
>>>
>>
>> No...as we've been very careful with those bundles (those that we
>> contribute to platform) to only make bug fixes on 2.X line.
>>
>>>
>>> I also think moving bundles up by a minor version during a point
>>> release will raise red flags for the PMC and will likely make it
>>> hard to get approved for this release.
>>>
>>
>> That's a real drag. Unlike the platform, we have point releases more >> frequently than once a year, and so we do most of our bug fixing on a 
>> 2.X and 3.0 branches rather than on a 2.0.X branch.  This so that we
>> don't have to maintain 3 (or more) branches (i.e. 2.0.X, 2.1.X, 3.0
>> [galileo], etc) during the entire year.
>>
>> I don't think that our minor release should raise a red flag, as
>> 'minor' to us is less major than the platform :)...particularly since 
>> we are being extremely careful with the platform plugins in
>> particular...to only do bug fixing in *anything* but major releases.
>>
>> So...I had intended to contribute ECF 2.1.0 to the 3.4.2 maintenance
>> release.  We can/could contribute a build called 2.0.2, but these
>> (platform contributed) plugins will be essentially the same...i.e.
>> there is no real content difference for these plugins...and it will
>> cause us futher releng/deployment effort and churn to do so. >> Obviously our releng churn isn't your PMC's major concern...but 
>> perhaps it could be considered a minor concern?  :).
>>
>> Also...we have to know somewhat in advance when/how this contribution 
>> is needed.  I assume it's not until after holidays, true?
>>
>> Scott
>>
>>
>>
>> _______________________________________________
>> p2-dev mailing list
>> p2-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/p2-dev
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

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

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

------------------------------------------------------------------------

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

Back to the top