[cross-project-issues-dev] Simultaneous Release Opt-in announcements

[Wayne Beaton]

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

[Ed Willink]

Hi Wayne

I don't think tracking the aggrcon will work since some projects specify
a 'my-build' repo and never need to touch the aggrcon; of course we all
get to enjoy the consequences of their broken builds. If everyone had to
specify a build specific repo, then aggrcon could work for this purpose.

You seem to have ignored the at least 3-way suggestion of using the PMI
Release Record. Obviously this requires that a Release Record is created
in order to have somewhere for the checkbox.

    Regards

        Ed Willink

Post by Wayne Beaton
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.
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Nick Boldt]

Back in the early wayback days of the eclipse trains, simrel opt-in was
done via a wiki page [0],[1].

[0] https://wiki.eclipse.org/Helios/Participating_Projects
[1] https://wiki.eclipse.org/Helios/Summary_of_Helios_Projects

Then there was a portal-based flag [2].

[2] https://wiki.eclipse.org/Category:Kepler

Using a wike page generates less email, so there's less of a spam factor /
annoyance.

But it also generates less email, so there's less of a reminder to opt in
by the deadline. :D

We could return to the simpler wiki ways, or acknowledge that there are now
dozens of projects in the train, and it's kind of fun to see how many
projects are actively announcing their intent to be at the party in
September.

(We could also use another tool too, if wiki is annoying. Doodle poll?
Google Form? Google Spreadsheet? Evite to the GA launch on Sept 19? FB
event on Sept 19?)

Post by Ed Willink
Hi Wayne
I don't think tracking the aggrcon will work since some projects specify a
'my-build' repo and never need to touch the aggrcon; of course we all get
to enjoy the consequences of their broken builds. If everyone had to
specify a build specific repo, then aggrcon could work for this purpose.
You seem to have ignored the at least 3-way suggestion of using the PMI
Release Record. Obviously this requires that a Release Record is created in
order to have somewhere for the checkbox.
Regards
Ed Willink
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.
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
_______________________________________________
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#m_-3488939442272430633_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>


“The Only Thing That Is Constant Is Change” - Heraclitus

[Daniel Megert]

Post by Ed Willink
You seem to have ignored the at least 3-way suggestion of using the PMI

Release Record. Obviously this requires that a Release Record is created
in order to have somewhere for the checkbox.

Exactly, see https://bugs.eclipse.org/520775.

Post by Ed Willink
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

Post by Ed Willink
valuable.

Well, this is only works for one out of four releases, since, as you said
yourself, the communication is only required once per year, but we 4
releases per year.

Dani



From: Ed Willink <***@willink.me.uk>
To: cross-project-issues-***@eclipse.org
Date: 16.07.2018 16:51
Subject: Re: [cross-project-issues-dev] Simultaneous Release Opt-in
announcements
Sent by: cross-project-issues-dev-***@eclipse.org



Hi Wayne
I don't think tracking the aggrcon will work since some projects specify a
'my-build' repo and never need to touch the aggrcon; of course we all get
to enjoy the consequences of their broken builds. If everyone had to
specify a build specific repo, then aggrcon could work for this purpose.
You seem to have ignored the at least 3-way suggestion of using the PMI
Release Record. Obviously this requires that a Release Record is created
in order to have somewhere for the checkbox.
Regards
Ed Willink

On 16/07/2018 15:38, Wayne Beaton wrote:
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-***@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



Virus-free. www.avast.com
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-***@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

[Doug Schaefer]

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-***@eclipse.org [mailto:cross-project-issues-dev-***@eclipse.org] On Behalf Of Wayne Beaton
Sent: Monday, July 16, 2018 10:38 AM
To: Cross project issues <cross-project-issues-***@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

[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

Post by Doug Schaefer
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.
*Sent:* Monday, July 16, 2018 10:38 AM
*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.
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev