Right now our master branch is still being using for Juno maintenance.
We'll put this into our Kepler builds when 1) we create our Juno
maintenance branch off the master (probably on Feb 25) and 2) the CQ is
approved. The earliest Kepler build that you'll see it would be Kepler
M6.
-- Dave
Hi
Stephan,
I’d
love to provide Commons Net 3.2 for Kepler but it has not been
ip-approved yet.
http://dev.eclipse.org/ipzilla/show_bug.cgi?id=7026
The
release was cast by Apache on 3-Dec-2012 – definitely too late to get
it approved and included in Juno SR2 but I much hope Kepler will work.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=346892#c7
For
the records, I had reported the deadlock problem with the 3.x version
to Apache on 24-May-2012,
(that
was after we had got 3.1 ip-approved and put into Orbit), but we’ve
been happily living with
Commons
Net 2.2 so far though I’m glad the issue is finally fixed.
Thanks,
Martin
--
Martin Oberhuber,
SMTS / Product Architect – Development Tools,
Wind
River
direct
+43.662.457915.85 fax +43.662.457915.6
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Tuesday, January 29, 2013 9:17 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Heads up ... new
"Recommended" Orbit repo for Juno SR2
It
is too late for SR2, for several reasons, but a great suggestion for
Kepler, if the TM project (or others) want it.
Just
to briefly outline the reasons, we are already up to RC2 and RC3, so I
think it'd have to be a "blocking problem" to cause all that stress, and
it doesn't sound like a blocking problem, from
what I've heard. I don't know who else uses it, but typically it's only
reasonable to give the "community" of projects and adopters a minimum
of a month, or two, notice of what's coming in a maintenance release,
especially if it involves a "major" version
change [And, I mean a month or two before the first release candidate,
not the "GA date"]. We in Orbit do have a generic "ramp down" process
for the purpose of stability, so it'd have to be a pretty strong case.
But, if you and the TM project think it is
a blocking problem, and worth the churn, feel free to open bugs, CQs,
etc., and continue to make your case. I'm just giving you my impression
from the little I know.
[I
would say it would have been a good suggestion a month or two ago, but
not sure when 3.2 was released, since the date on their web site says
"TBA" (even though it appears to be available for
download), so, maybe just released?]
And,
Kepler is not that far away. I don't recall seeing the "CQ deadline"
for Kepler officially announced recently by the Eclipse Foundation, but
its typically "M5" which is just a couple of weeks
away (February 8). (Its not that they can not be submitted after that,
but those submitted by the M5 deadline allows for proper planning, etc.
and thus given higher priority, all else being equal). But, I'm not
specking for the Eclipse Foundation ... I hope
they weren't waiting for me :) .... just saying what it has been in the
past several yearly releases.
This
is probably not a very constructive reply (and not what you wanted to
hear) ... but, I do think we need to focus on stability for Juno, and
new things for Kepler.
Thanks
for bringing it up, though.
From:
Stephan
Leicht Vogt <Stephan.Leicht@xxxxxxxxx>
To:
"cross-project-issues-dev@xxxxxxxxxxx"
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
01/29/2013
01:51 AM
Subject:
Re:
[cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo
for Juno SR2
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
It is too late for SR2, for several
reasons, but a great suggestion for Kepler, if the TM project (or
others)
want it.
Just to briefly outline the
reasons,
we are already up to RC2 and RC3, so I think it'd have to be a "blocking
problem" to cause all that stress, and it doesn't sound like a blocking
problem, from what I've heard. I don't know who else uses it, but
typically
it's only reasonable to give the "community" of projects and
adopters a minimum of a month, or two, notice of what's coming in a
maintenance
release, especially if it involves a "major" version change [And,
I mean a month or two before the first release candidate, not the "GA
date"]. We in Orbit do have a generic "ramp down" process
for the purpose of stability, so it'd have to be a pretty strong case.
But, if you and the TM project think it is a blocking problem, and
worth the churn, feel free to open bugs, CQs, etc., and continue to make
your case. I'm just giving you my impression from the little I know.
[I would say it would have been a
good
suggestion a month or two ago, but not sure when 3.2 was released, since
the date on their web site says "TBA" (even though it appears
to be available for download), so, maybe just released?]
And, Kepler is not that far away. I
don't recall seeing the "CQ deadline" for Kepler officially announced
recently by the Eclipse Foundation, but its typically "M5" which
is just a couple of weeks away (February 8). (Its not that they can not
be submitted after that, but those submitted by the M5 deadline allows
for proper planning, etc. and thus given higher priority, all else being
equal). But, I'm not specking for the Eclipse Foundation ... I hope they
weren't waiting for me :) .... just saying what it has been in the past
several yearly releases.
This is probably not a very
constructive
reply (and not what you wanted to hear) ... but, I do think we need to
focus on stability for Juno, and new things for Kepler.
Thanks for bringing it up, though.
From:
Stephan Leicht Vogt
<Stephan.Leicht@xxxxxxxxx>
To:
"cross-project-issues-dev@xxxxxxxxxxx"
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
01/29/2013 01:51 AM
Subject:
Re:
[cross-project-issues-dev]
Heads up ... new "Recommended" Orbit repo for Juno SR2
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi
Some text went missing in the last mail. At least a:
Greetings
Stephan
---
Stephan Leicht Vogt
Senior Software Engineer
BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com
On Jan 29, 2013, at 6:48 AM, Stephan Leicht Vogt <Stephan.Leicht@xxxxxxxxx>
wrote:
Hi all
Wouldn't it be better in this
situation
to pack the newest Version 3.2 from commons net to Orbit. Even if this
comes up a little late and the R Version of Orbit is already promoted
for
Juno SR2. As Apache has released 3.2 this would be IMHO the better way
than to pack an version which is two years old into the EPP. I would do
the update but David Dykstal would have to open a (high prio?) CQ from
the TM Project to use Apache Commons Net 3.2 so Orbit could open a
piggyback.
What do you think? Or
- From: "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Thu, 24 Jan 2013
18:30:34 +0000
- Accept-language: en-US
- Delivered-to: cross-project-issues-dev@xxxxxxxxxxx
- Thread-index:
AQHN+leHmRtU+ONw4kCQt/T6cQwZMJhZRdgAgAAH+ID//34PkA==
- Thread-topic:
[cross-project-issues-dev]
Heads up ... new "Recommended" Orbit repo for Juno SR2
Hi
David (and
all),
We only want a
build-time
selection of Commons Net 2.2 from Orbit.
The MANIFEST.MF
at runtime
should be open to allow [2.2,4.0) or even higher (as per the recent
ICU4J
discussion).
The reason for
picking
2.2 by default is that it’s known to work safely whereas 3.1 can produce
a deadlock in some situations with Telnet.
End users should
be able
to deploy 3.2 (which is not in Orbit yet) or 3.1 (if they are not
affected
by the deadlock situation).
Does anybody
know how to
enforce a particular bundle version install at build time with Maven ?
Thanks,
Martin |
---
Stephan Leicht Vogt
Senior Software Engineer
BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com
[attachment "smime.p7s" deleted
by David M Williams/Raleigh/IBM] _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
January 29, 2013
12:50 AM
Hi
Some text went missing in the last mail. At least a:
Greetings
Stephan
---
Stephan Leicht Vogt
Senior Software Engineer
BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com
January 28, 2013
11:48 PM
Hi all
Wouldn't it be better in this situation to pack the newest Version
3.2 from commons net to Orbit. Even if this comes up a little late and
the R Version of Orbit is already promoted for Juno SR2. As Apache has
released 3.2 this would be IMHO the better
way than to pack an version which is two years old into the EPP. I
would do the update but David Dykstal would have to open a (high prio?)
CQ from the TM Project to use Apache Commons Net 3.2 so Orbit could open
a piggyback.
What do you think? Or
Hi
David (and all),
We
only want a build-time selection of Commons Net 2.2 from Orbit.
The
MANIFEST.MF at runtime should be open to allow [2.2,4.0) or even higher
(as per the recent ICU4J discussion).
The
reason for picking 2.2 by default is that it’s known to work safely
whereas 3.1 can produce a deadlock in some situations
with Telnet.
End
users should be able to deploy 3.2 (which is not in Orbit yet) or 3.1
(if they are not affected by the deadlock situation).
Does
anybody know how to enforce a particular bundle version install at build
time with Maven ?
Thanks,
Martin
|
---
Stephan Leicht Vogt
Senior Software Engineer
BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com
|