[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in
/home/data/httpd/download.eclipse.org/linuxtools/update-docker-2.3.1/plugins,
but it's definitely not in the aggregated repo.


On 20.04.2017 18:31, Jeff Johnston wrote:
> Fred,
> 
> The version of httpclient also changed in our update-docker-2.3.1 repo from:
> 
> org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643
> 
> to:
> 
> org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925
> 
> Not sure why this change isn't being seen as well.
> 
> -- Jeff J.
> 
> 
> 
> On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr
> <frederic.gurr@xxxxxxxxxxx <mailto:frederic.gurr@xxxxxxxxxxx>> wrote:
> 
>     Thanks Jeff,
> 
>     I ran a SimRel aggregation build. The only change I can see in the list
>     of "Non Unique Versions used in repository" is that a different version
>     of org.apache.httpcomponents.httpcore is now used. Instead of
>     4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925.
> 
>     I compared
>     http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt
>     <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt>
>     and
>     https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
>     <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>
> 
>     @All: is that the intended result?
> 
>     Regards,
> 
>     Fred
> 
> 
>     On 19.04.2017 20:21, Jeff Johnston wrote:
>     > Hi Fred,
>     >
>     > I have just pushed a change to gerrit:
>     https://git.eclipse.org/r/#/c/95308/
>     <https://git.eclipse.org/r/#/c/95308/>
>     >
>     > I only changed the docker repository and left the other Linux Tools
>     > features alone
>     > since they were only bumped as part of the point release to fix the
>     > Docker Tooling plug-ins.
>     >
>     > I assume I can merge the patch if the gerrit verification is
>     > successful.  If this is wrong,
>     > let me know.
>     >
>     > -- Jeff J.
>     >
>     > On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr
>     > <frederic.gurr@xxxxxxxxxxx <mailto:frederic.gurr@xxxxxxxxxxx>
>     <mailto:frederic.gurr@xxxxxxxxxxx
>     <mailto:frederic.gurr@xxxxxxxxxxx>>> wrote:
>     >
>     >     Hi,
>     >
>     >     Can you provide a patch for the SimRel build (branch
>     "Neon.3_respin")
>     >     that references the new version?
>     >
>     >     Regards,
>     >
>     >     Fred
>     >
>     >     On 19.04.2017 17:27, Jeff Johnston wrote:
>     >     > Hi Ed,
>     >     >
>     >     > Linux tools spun a 5.3.1 release which now has a 2.3.1
>     version of
>     >     docker
>     >     > tooling.  The Linux tools download site has
>     update-docker-2.3.1 and
>     >     > update-docker, both which have 2.3.1 versions of the docker.core
>     >     plug-in
>     >     > and docker feature.  Not sure why you are not seeing this.
>     >     >
>     >     > -- Jeff J.
>     >     >
>     >     > On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks
>     <ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>
>     >     <mailto:ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>>
>     >     > <mailto:ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>
>     <mailto:ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>>>> wrote:
>     >     >
>     >     >     Frederic,
>     >     >
>     >     >     There seem to have been no notes/minutes taken during
>     the meeting:
>     >     >
>     >     >     
>      https://wiki.eclipse.org/Planning_Council/April_05_2017
>     <https://wiki.eclipse.org/Planning_Council/April_05_2017>
>     >     <https://wiki.eclipse.org/Planning_Council/April_05_2017
>     <https://wiki.eclipse.org/Planning_Council/April_05_2017>>
>     >     >     <https://wiki.eclipse.org/Planning_Council/April_05_2017
>     <https://wiki.eclipse.org/Planning_Council/April_05_2017>
>     >     <https://wiki.eclipse.org/Planning_Council/April_05_2017
>     <https://wiki.eclipse.org/Planning_Council/April_05_2017>>>
>     >     >
>     >     >     I recall agreeing to provide steps for reproducing the
>     problem so
>     >     >     that Thomas Watson could test if the wiring resolution
>     fix he made
>     >     >     for Oxygen also solves the problem for Neon.3.  The fact
>     that he
>     >     >     encountered "the mirroring problem" didn't help in that
>     regard:
>     >     >
>     >     >       https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
>     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
>     >     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
>     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>
>     >     >     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
>     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>
>     >     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213
>     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>>
>     >     >
>     >     >     In the end, he sent me a note saying (and I quote):
>     >     >
>     >     >>     I see that now there is the same number of
>     httpcomponents bundles
>     >     >>     as there was in the messed up Oxygen M6 builds.  But
>     here my back
>     >     >>     port of the resolver fix does not seem to have fixed
>     the issue.
>     >     >>     I'm unsure if that is because it gave up with the sheer
>     number of
>     >     >>     bundles or if something else is going wrong.  But at
>     this point
>     >     >>     the backport of the resolver fix does not seem to be
>     the solution
>     >     >>     to the problem.
>     >     >
>     >     >     I assumed (wrongly I guess) that Thomas would
>     investigate a more
>     >     >     general fix to address the wiring problem.
>     >     >
>     >     >     In the end, I also wasn't sure which version of the docker
>     >     tools is
>     >     >     proposed for contribution to Neon.3a.  I tried to search for
>     >     update
>     >     >     sites containing it like this:
>     >     >
>     >     >     Nothing looks like a new version of 2.3.  Goodness knows
>     where one
>     >     >     should find what's being proposed for contribution...
>     >     >
>     >     >     In any case, the proposed "solution" (A) really just
>     changes the
>     >     >     version of httpclient to be one that's not broken (missing
>     >     >     packages), but it doesn't change the wiring problem in any
>     >     >     fundamental way.  There will still be the four versions that
>     >     can all
>     >     >     be installed simultaneously, so we really should expect
>     the same
>     >     >     wiring problem(s).  In fact, I believe Oxygen M6 has
>     >     effectively the
>     >     >     same four httpcomponents.httpclient bundle as does
>     Neon.3, so
>     >     I'm a
>     >     >     little suspicious whether the wiring problem is in fact
>     really
>     >     fixed
>     >     >     even for Oxygen.  We won't know until M7 and that's a
>     month away.
>     >     >     It doesn't give me warm fuzzy feelings.
>     >     >
>     >     >     So at this point it remains unclear the nature of the wiring
>     >     >     problem(s).  Is it a bug? Is it fixable? Does the
>     knowledge, will,
>     >     >     and capacity to fix it exist?
>     >     >
>     >     >     Without a fix to the wiring problem I think we can
>     eliminate A
>     >     as a
>     >     >     solution, leaving B, C, and D (i.e., focus on problem
>     avoidance
>     >     >     approaches).  But I think if the wiring problem is a
>     bug, it will
>     >     >     come back, and it will raise its ugly head again when users
>     >     install
>     >     >     various technologies from various sources.  To my
>     thinking, fixing
>     >     >     the bug seems important.
>     >     >
>     >     >     Regards,
>     >     >     Ed
>     >     >
>     >     >
>     >     >     On 19.04.2017 12:49, Frederic Gurr wrote:
>     >     >>     Hi Ed,
>     >     >>
>     >     >>     In the last planning-council meeting you offered to
>     evaluate
>     >     if the
>     >     >>     fixed Linux Tools package works as expected and if
>     there are
>     >     still
>     >     >>     wiring issues.
>     >     >>
>     >     >>     Can you give us an update on the current state?
>     >     >>
>     >     >>     Regards,
>     >     >>
>     >     >>     Fred
>     >     >>
>     >     >>     On 31.03.2017 11:14, Ed Merks wrote:
>     >     >>>     Hi,
>     >     >>>
>     >     >>>     The original thread is fractured into many threads so its
>     >     kind of
>     >     >>>     impossible to follow each thread with a reply but I'll try
>     >     at the bottom
>     >     >>>     of this note, i.e., below the ===========
>     >     >>>
>     >     >>>     But before doing that, I'd like to re-focus on the most
>     >     important
>     >     >>>     questions: *We currently have a problem with Neon.3,
>     will we
>     >     fix it, and
>     >     >>>     if so how will we fix it?*
>     >     >>>
>     >     >>>     The discussion has quickly digressed (constructively) into
>     >     solving the
>     >     >>>     issue of how Orbit dependencies should be managed by
>     >     projects and by the
>     >     >>>     release train.  Unfortunately I see this as a world hunger
>     >     issue; not
>     >     >>>     one that is easily addressed and I believe not one we can
>     >     wait for in
>     >     >>>     order to solve the Neon.3 problem.  Let's face it,
>     we've not
>     >     been able
>     >     >>>     to produce a proper Oxygen milestone in months, we still
>     >     don't have one
>     >     >>>     now, and we won't have one until next month, we hope.
>     >     >>>
>     >     >>>     For Neon we've done three maintenance releases.  Neon.1
>     >     needed a respin
>     >     >>>     and Neon.3 looks to be in need of the same thing.  Clearly
>     >     something is
>     >     >>>     seriously wrong.  But if we spend our time on solving the
>     >     Orbit world
>     >     >>>     hunger issue, will we arrive at a solution in time for
>     >     Oxygen, let alone
>     >     >>>     in time to fix Neon.3?  I am very, very doubtful.
>     >     >>>
>     >     >>>     As another data point, if I install the
>     >     egg-laying-wool-milk-pig for
>     >     >>>     Neon.3.  The following happens.  I'm prompted to
>     accept this
>     >     license:
>     >     >>>
>     >     >>>         Red Hat, Inc. licenses these features and plugins
>     to you
>     >     under
>     >     >>>         certain open source licenses (or aggregations of such
>     >     licenses),
>     >     >>>         which in a particular case may include the Eclipse
>     >     Public License,
>     >     >>>         the GNU Lesser General Public License, and/or certain
>     >     other open
>     >     >>>         source licenses. For precise licensing details,
>     consult the
>     >     >>>         corresponding source code, or contact Red Hat,
>     Attn: General
>     >     >>>         Counsel, 100 East Davie St., Raleigh NC 27601 USA.
>     >     >>>
>     >     >>>     I'm not sure how this license slipped into the release
>     >     train.   Aren't
>     >     >>>     there checks for this?  (Sorry to digress, but this is
>     also
>     >     unacceptable.)
>     >     >>>
>     >     >>>     Launching the final installation comes up like this:
>     >     >>>
>     >     >>>     Clearly a disgusting mess, but I've mentioned that before
>     >     and the same
>     >     >>>     projects are still doing the same bad things, so we
>     clearly
>     >     all accept
>     >     >>>     this situation as normal.
>     >     >>>
>     >     >>>     The most important point here is the error log (first
>     >     attachment) is
>     >     >>>     full of exactly the problem indications (bundle wiring
>     >     problems) we
>     >     >>>     should have expected from the Neon.3 repository's
>     contents,
>     >     if someone
>     >     >>>     were to install an arbitrary combination of the
>     repository's
>     >     contents.
>     >     >>>     It's really not so hard to test this!
>     >     >>>
>     >     >>>     If I create the same installation with my local build
>     of the
>     >     Oomph 1.8
>     >     >>>     installer---which installs my locally built version of
>     Oomph
>     >     1.8 so the
>     >     >>>     Oomph setup plugins are no longer disabled because I
>     made the
>     >     >>>     userstorage dependency optional and eliminated the strict
>     >     <=4.4 upper
>     >     >>>     bound constraints on httpclient, which was such a bad
>     idea I
>     >     can almost
>     >     >>>     have a canary to think this done to solve a problem
>     with no
>     >     anticipation
>     >     >>>     of the problems it would cause---then I can visit all the
>     >     preference
>     >     >>>     pages producing the second attached much larger log.  It
>     >     seems clear
>     >     >>>     that proper testing really doesn't happen for far too many
>     >     projects on
>     >     >>>     the train.  With distributed responsibility, no one is
>     >     really responsible...
>     >     >>>
>     >     >>>     ==================================
>     >     >>>
>     >     >>>     Orbit Issues
>     >     >>>
>     >     >>>     1) Respinning Linux Tools against Oxygen Mx seems to miss
>     >     the point that
>     >     >>>     we should only distribute released versions of
>     bundles,  so
>     >     no Neon
>     >     >>>     build should redistribute any unreleased version of
>     >     anything.  If a new
>     >     >>>     version of something is needed for security reasons or
>     other
>     >     reasons, it
>     >     >>>     should be released first.  And doing that in a maintenance
>     >     train without
>     >     >>>     testing the overall impact is clearly something we should
>     >     never do again
>     >     >>>     (without waving a bunch of red flags of warning).  And
>     as Martin
>     >     >>>     Oberhuber asks, is nothing in place to check for this?  So
>     >     suppose we do
>     >     >>>     respin with a fixed released version, like what we
>     have for
>     >     Oxygen M6,
>     >     >>>     then most likely we'd still have the problems we have in
>     >     Oxygen M6 so
>     >     >>>     we'd need a fix to the resolver in Neon.  Better would
>     seem
>     >     to respin
>     >     >>>     with the old version(s) of the Orbit bundles, but
>     somehow we
>     >     can never
>     >     >>>     delete the broken version from Neon and because it has a
>     >     higher version
>     >     >>>     number is likely to slip back in unexpected (though
>     >     hopefully not, given
>     >     >>>     that features have pinned their bundle versions).
>     >     >>>
>     >     >>>     2) Don't include Orbit bundles in your project's features.
>     >     Sounds like
>     >     >>>     a great idea, but begs endless questions, and while
>     solving
>     >     a problem
>     >     >>>     might well introduce more new problems than it
>     solves.  The
>     >     first
>     >     >>>     question (as Carsten points out) is how do these
>     things end
>     >     up in a
>     >     >>>     repository, and if they are in a repository somehow,
>     how are
>     >     they
>     >     >>>     categorized?  It's hard to get them in and once you
>     do, they're
>     >     >>>     categorized poorly.  The next question is, how do they end
>     >     up in the
>     >     >>>     release train, if the projects that need them don't
>     >     contribute them?
>     >     >>>     Directly from Orbit you say?  But which ones should be
>     >     pulled in from
>     >     >>>     Orbit and how is that discovered?   Are those the ones the
>     >     projects have
>     >     >>>     tested against? Then there is the question of whether an
>     >     installation is
>     >     >>>     deterministic if the bundle version isn't pinned? 
>     It's not;
>     >     it will
>     >     >>>     depend on what's in the repos that are available at
>     resolve
>     >     time.  But
>     >     >>>     Gunnar argues that even packages are not deterministic,
>     >     which I think is
>     >     >>>     false: if the feature pins the bundle version and the
>     >     package requires
>     >     >>>     the feature, then the pinned bundle is definitely in that
>     >     package.  But
>     >     >>>     regardless, Gunnar's important point is that the runtime
>     >     wiring seems
>     >     >>>     kind of non-determinstic, and while uses constraints might
>     >     help, who the
>     >     >>>     heck understands those well, what tooling produces it
>     >     correctly for us,
>     >     >>>     is that nicely integrated in PDE, and will it be properly
>     >     maintained (in
>     >     >>>     contrast to lower bound constraints which you can pretty
>     >     expect will
>     >     >>>     remain on whatever stale version they were initially set
>     >     to).  This may
>     >     >>>     well be the right direction in which to go, but getting
>     >     there isn't
>     >     >>>     going to be even half the fun...
>     >     >>>
>     >     >>>     Regards,
>     >     >>>     Ed
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>     _______________________________________________
>     >     >>>     cross-project-issues-dev mailing list
>     >     >>>     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
>     >     >>>     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
>     >     >>>     To change your delivery options, retrieve your
>     password, or
>     >     unsubscribe from this list, visit
>     >     >>>
>     >     
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>     >     >>>
>     >     
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>     >     >>>
>     >     >>     _______________________________________________
>     >     >>     cross-project-issues-dev mailing list
>     >     >>     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
>     >     >>     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
>     >     >>     To change your delivery options, retrieve your password, or
>     >     unsubscribe from this list, visit
>     >     >>
>     >     
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>     >     >>
>     >     
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>     >     >
>     >     >
>     >     >     _______________________________________________
>     >     >     cross-project-issues-dev mailing list
>     >     >     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
>     >     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>>
>     >     >     To change your delivery options, retrieve your password, or
>     >     >     unsubscribe from this list, visit
>     >     >
>     >     
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>     >     >
>     >     
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>>
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > cross-project-issues-dev mailing list
>     >     > cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
>     >     > To change your delivery options, retrieve your password, or
>     >     unsubscribe from this list, visit
>     >     >
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>     >     >
>     >     _______________________________________________
>     >     cross-project-issues-dev mailing list
>     >     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     >     <mailto:cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
>     >     To change your delivery options, retrieve your password, or
>     >     unsubscribe from this list, visit
>     >   
>      https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >   
>      <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > cross-project-issues-dev mailing list
>     > cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     > To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>     >
>     _______________________________________________
>     cross-project-issues-dev mailing list
>     cross-project-issues-dev@xxxxxxxxxxx
>     <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>     <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> 
> 
> 
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>