The fix for http://bugs.eclipse.org/258680 and http://bugs.eclipse.org/237936 is the one thing that could motivate
moving IMHO. In the absence of any other critical issues I'd stay on
the older version of ECF that shipped with 3.4.
The integration of those fixes caused some churn. Do you think it
would cause churn/unstability again given that we know the issues now?
Would users be affected in some adverse way? (not pushing for the fix,
just curoious)
As for the HTTP client stuff, well, just seeing it mentioned in the
context of 3.4.2 made me a little dizzy and I had to lie down for a
minute.
Jeff
Pascal Rapicault wrote:
First, I did not mean to drop the discussion on this. I just
wanted to differ until everyone was back from vacation (apparently
earlier than expected :-)).
While you were writing this note I happened to run a comparison of the
6 ECF plug-ins p2 relies on. I compared the content of the CVS tags
v20080611-1715 and v20081224-1728 and here are my results:
** ecf
Minor change in ContainerFactory. API not used by p2
Version change to 2.0.1
** ecf.filetransfer
Java doc change.
Version change to 2.0.1
** ecf.identity
No code change
Version change to 2.0.1
** ecf.provider.filetransfer
Change for sending out close connection - http://bugs.eclipse.org/247197
Transfer content using gzip bug http://bugs.eclipse.org/237936
Version change to 2.0.1
** ecf.provider.filetransfer.ssl
No code change
version change to 1.0.1
** ecf.ssl
No code change
Version change to 1.0.1
Scott, do you concur with those results?
>From this analysis it looks like the version number of the ECF
release is making things scarier than they are; after all, most
plug-ins did not change. However because of the problems we have had
around the introduction of the gzipped support (see http://bugs.eclipse.org/258680) I would rather keep on shipping
with the version we used in 3.4.0 since even the fix for 247197 did not
completely get rid of the deadlock problem and we had to resort to ship
with http client in 3.5.
What do others think?
As for shipping with the http client support , I think this would
likely give the PMC a stroke and given that users still have the
ability to add it after the fact it is not really an urgency.
The M builds are running every wednesday morning http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html
PaScaL
 Scott Lewis
---12/30/2008 01:30:36 PM---Ok, I break things down below but the
summary is that the only substantive difference (other than j
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
>>
>
_______________________________________________
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
|
