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 <dschae...@blackberry.com> 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 <cross-project-issues-dev@eclipse.org> > *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
