Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Andreas Sewe]

Nick Boldt wrote:
> * o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Nick, are you sure? I just checked and all I can see are Import-Packages
on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.

Can you please clarify?

Best wishes,

Andreas

[1] 

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] CDT 9.5.3 participation in 2018.09

[Jonah Graham]

Hi folks,

As previously announced we plan to do a service release of CDT 9.5. This is
currently expected to be CDT 9.5.3.

CDT contributes at Offset +1.

Release record:
https://projects.eclipse.org/projects/tools.cdt/releases/9.5.3

Thanks
Jonah


~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On Mon, 16 Jul 2018 at 16:25, Doug Schaefer 
wrote:

> CDT is participating, of course. We don’t know what release yet. At this
> point it’s very likely a maintenance release off the 9.5 branch. But as we
> are pushing those out on demand, we won’t know which one until the rampdown
> starts when we’ll lock it in.
>
>
>
> But, yes, at the very least can we create another mailing list for these.
> It’s created a lot of noise in my inbox and we have other very important
> topics to look out for.
>
>
>
> Doug.
>
>
>
> *From:* cross-project-issues-dev-boun...@eclipse.org [mailto:
> cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Wayne Beaton
> *Sent:* Monday, July 16, 2018 10:38 AM
> *To:* Cross project issues 
> *Subject:* [cross-project-issues-dev] Simultaneous Release Opt-in
> announcements
>
>
>
> These "kind of annoying" announcement messages serve a couple of purposes.
>
>
>
> They ensure that project teams are actually engaged on the primary
> communication channel for the simultaneous release. This comes in handy,
> for example, when project teams change composition (e.g. key players move
> on), knowledge gets lost, or project teams otherwise end up disengaged.
> When we notice that projects are missing at the opt-in deadline, it's way
> easier to mitigate than when we notice it at the end of the release cycle.
> FWIW, we have to chase down at least a couple of projects every year.
>
>
>
> The requirement to make an explicit communication basically forces project
> teams to create a release record and start their planning and communication
> regarding the release. Of course, this presupposes that creating a release
> record at the beginning of a release cycle is valuable.
>
>
>
> The Eclipse Development Process states, in part:
>
>
>
> Projects are required to make a project plan available to their community
> at the beginning of the development cycle for each major and minor release.
> The plan may be as simple as a short description and a list of issues, or
> more detailed and complex.
>
>
>
> The Architecture Council is in the process of updating the Eclipse
> Development Process. If anybody would like to consider changing any of
> these, I recommend that you take that up with your PMC representative on
> the council.
>
>
>
> With the evolution of the simultaneous release to a rolling release
> process, I half expected that the Planning Council might decide to require
> explicit opt-in on a quarterly basis. I'm delighted that they've instead
> decided to not raise the burden and instead just require a single annual
> check in.
>
>
>
> I am thinking, though, that with the increase in frequency of releases,
> it's time to rethink how we track participation in the release. We may
> consider investing some energy in deriving this information from the
> aggrcon files. This, of course, assumes that tracking this information is
> actually valuable (and ignores that we have some projects that participate
> in the simultaneous release, but do not contribute bits to the aggregate
> repository). The explicit tracking has proven helpful for marketing
> purposes, and helps those of us who work at a higher level than an
> individual project.
>
>
>
> I don't know how to achieve all of this in an easier manner than a
> once-per-year email. If you have suggestions for alternatives, please
> connect with your PMC's Planning Council representative to have them bring
> this discussion to the PC.
>
>
>
> Thanks,
>
>
> Wayne
>
> --
>
> Wayne Beaton
>
> Director of Open Source Projects
>
> The Eclipse Foundation
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev