[cross-project-issues-dev] 2018-12 opt-in

[Wayne Beaton]

No explicit opt-in is required for returning projects. We're going to sort
this out automatically from the aggregation files.

Note that aggregation files need to be authored such that builds are
repeatable. That is, you cannot point your aggregation file to the "lastest
and greatest"; it must point to a specific version of your software.

Any project that wishes to join the simultaneous release, but did not
participate in the previous iteration needs to announce their intent to
participate by the M1 date (October 19). If you are leaving the
simultaneous release, please turn off or remove your aggregation file; an
announcement on this list would be very helpful.

If your project is introducing breaking change or is otherwise adding
functionality that may have downstream impact, we expect that you will
announce these changes as early as possible via this list.

If you are planning a new major or minor release, please enter your
project's release record into the PMI by the M1 date (October 19). Release
records are not required for service releases.

Note that your project must be consistent with the IP Policy at all times.
Releases, even service releases, may only contain third party IP that has
been resolved by the IP Team.

No new functionality can be added in any Release Candidate. If you are
contributing new bits to this instance of the simultaneous release, you
must participate in the milestones.

I will be posting a complete list of dates on the wiki later today or
tomorrow. Further updates as events warrant.

Wayne

[Pierre-Charles David]

Post by Wayne Beaton
No explicit opt-in is required for returning projects. We're going to
sort this out automatically from the aggregation files.

Could you clarify how exactly this will be "sorted out"? From what I
understood at yesterday's planning council meeting [1], the idea was to
disable everyone's contribution at the start of a new cycle and to
expect each project to explicitly re-enable its contribution before M1.
Is that correct?

After discussing with other project leads here at Obeo we feel this
approach (if this is indeed what is proposed) would be too disruptive.
We've tried this before, and the result was not good, with the first
milestone(s) often completely broken. It would be enough for a single
project on which others depend to be late to completely break the
aggregation. Given the reduced number of milestones we have now, this
would be really bad.

I think the idea of relying on an explicit action in "the aggregation
files" to declare intent is good, but using the enablement flag too
risky. Maybe we could have another mechanism in the repo for that. How
about something as simple as a "participation.txt" text file with a
single line per project:

PMF: 2018-12
XWT: 2018-12
actf: 2018-12
acute: 2018-12
birt: 2018-12
...

Declaring intent to participate would simply involve editing the
corresponding line with the version of the next release.

Regards,
Pierre-Charles David (Obeo)

[1] https://wiki.eclipse.org/Planning_Council/October_3_2018

[Matthias Sohn]

On Thu, Oct 4, 2018 at 11:21 AM Pierre-Charles David

Post by Pierre-Charles David

Post by Wayne Beaton
No explicit opt-in is required for returning projects. We're going to
sort this out automatically from the aggregation files.

Could you clarify how exactly this will be "sorted out"? From what I
understood at yesterday's planning council meeting [1], the idea was to
disable everyone's contribution at the start of a new cycle and to
expect each project to explicitly re-enable its contribution before M1.
Is that correct?
After discussing with other project leads here at Obeo we feel this
approach (if this is indeed what is proposed) would be too disruptive.
We've tried this before, and the result was not good, with the first
milestone(s) often completely broken. It would be enough for a single
project on which others depend to be late to completely break the
aggregation. Given the reduced number of milestones we have now, this
would be really bad.

+1

Post by Pierre-Charles David
I think the idea of relying on an explicit action in "the aggregation
files" to declare intent is good, but using the enablement flag too
risky. Maybe we could have another mechanism in the repo for that. How
about something as simple as a "participation.txt" text file with a
PMF: 2018-12
XWT: 2018-12
actf: 2018-12
acute: 2018-12
birt: 2018-12
...

I think there is no need to repeat this version name for all entries
in this file.
Use yaml or json format instead to avoid the repetition

participation.yaml:

version: 2018-12
projects:
- PMF
- XWT
- actf
- acute
- birt
...

Post by Pierre-Charles David
Declaring intent to participate would simply involve editing the
corresponding line with the version of the next release.
Regards,
Pierre-Charles David (Obeo)
[1] https://wiki.eclipse.org/Planning_Council/October_3_2018
_______________________________________________
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

[Mickael Istria]

Hi,

Maybe instead of a new file, we can add an "intent" flag on the aggrcon
files, and this would be reset to "false" after every release. Projects
would be expected to change it to true to state their intent; but it
wouldn't automatically disable a project.

[Ed Willink]

Hi

Yes a mandatory manual enabling at M1 was very disruptive, but ...

There has long been an expectation that releases should demonstrate that
they are SimRel compatible. i.e. build against the latest Orbit +
platform + ... A maintenance release contribution is therefore unavoidable.

The tolerance of 'latest & greatest' aggrcon contributions is to be
terminated, so projects will have to make a manual *.aggrcon change anyway.

Perhaps the automated disable can be enforced at M2 for those projects
that have failed to make a contribution prior to M2+0 day.

    Regards

        Ed Willink

Post by Matthias Sohn
On Thu, Oct 4, 2018 at 11:21 AM Pierre-Charles David

Post by Pierre-Charles David

Post by Wayne Beaton
No explicit opt-in is required for returning projects. We're going to
sort this out automatically from the aggregation files.

Could you clarify how exactly this will be "sorted out"? From what I
understood at yesterday's planning council meeting [1], the idea was to
disable everyone's contribution at the start of a new cycle and to
expect each project to explicitly re-enable its contribution before M1.
Is that correct?
After discussing with other project leads here at Obeo we feel this
approach (if this is indeed what is proposed) would be too disruptive.
We've tried this before, and the result was not good, with the first
milestone(s) often completely broken. It would be enough for a single
project on which others depend to be late to completely break the
aggregation. Given the reduced number of milestones we have now, this
would be really bad.

+1

Post by Pierre-Charles David
I think the idea of relying on an explicit action in "the aggregation
files" to declare intent is good, but using the enablement flag too
risky. Maybe we could have another mechanism in the repo for that. How
about something as simple as a "participation.txt" text file with a
PMF: 2018-12
XWT: 2018-12
actf: 2018-12
acute: 2018-12
birt: 2018-12
...

I think there is no need to repeat this version name for all entries
in this file.
Use yaml or json format instead to avoid the repetition
version: 2018-12
- PMF
- XWT
- actf
- acute
- birt
...

Post by Pierre-Charles David
Declaring intent to participate would simply involve editing the
corresponding line with the version of the next release.
Regards,
Pierre-Charles David (Obeo)
[1] https://wiki.eclipse.org/Planning_Council/October_3_2018
_______________________________________________
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

_______________________________________________
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

[Ed Merks]

Doesn't this overlook the fact that with the rapid rate of releases,
projects will/can choose to contribute their most recent release without
change?

If we start auto-disabling contributions I can guarantee that we will
not get a first spin off the ground.  Try to remove EMF's contribution
automatically and see how well that actually works.

Post by Ed Willink
Hi
Yes a mandatory manual enabling at M1 was very disruptive, but ...
There has long been an expectation that releases should demonstrate
that they are SimRel compatible. i.e. build against the latest Orbit +
platform + ... A maintenance release contribution is therefore
unavoidable.
The tolerance of 'latest & greatest' aggrcon contributions is to be
terminated, so projects will have to make a manual *.aggrcon change anyway.
Perhaps the automated disable can be enforced at M2 for those projects
that have failed to make a contribution prior to M2+0 day.
    Regards
        Ed Willink

Post by Matthias Sohn
On Thu, Oct 4, 2018 at 11:21 AM Pierre-Charles David

Post by Pierre-Charles David

Post by Wayne Beaton
No explicit opt-in is required for returning projects. We're going to
sort this out automatically from the aggregation files.

Could you clarify how exactly this will be "sorted out"? From what I
understood at yesterday's planning council meeting [1], the idea was to
disable everyone's contribution at the start of a new cycle and to
expect each project to explicitly re-enable its contribution before M1.
Is that correct?
After discussing with other project leads here at Obeo we feel this
approach (if this is indeed what is proposed) would be too disruptive.
We've tried this before, and the result was not good, with the first
milestone(s) often completely broken. It would be enough for a single
project on which others depend to be late to completely break the
aggregation. Given the reduced number of milestones we have now, this
would be really bad.

+1

Post by Pierre-Charles David
I think the idea of relying on an explicit action in "the aggregation
files" to declare intent is good, but using the enablement flag too
risky. Maybe we could have another mechanism in the repo for that. How
about something as simple as a "participation.txt" text file with a
PMF: 2018-12
XWT: 2018-12
actf: 2018-12
acute: 2018-12
birt: 2018-12
...

I think there is no need to repeat this version name for all entries
in this file.
Use yaml or json format instead to avoid the repetition
version: 2018-12
     - PMF
     - XWT
     - actf
     - acute
     - birt
...

Post by Pierre-Charles David
Declaring intent to participate would simply involve editing the
corresponding line with the version of the next release.
Regards,
Pierre-Charles David (Obeo)
[1] https://wiki.eclipse.org/Planning_Council/October_3_2018
_______________________________________________
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

_______________________________________________
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
_______________________________________________
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

[Mickael Istria]

Post by Ed Willink
projects will have to make a manual *.aggrcon change anyway.

That's not mandatory. A project may ship in 2018-12 the same content as in
2018-09 thus does not need to update the *.aggrcon file.
We need something explicit about the intent, that's not correlated to the
actual contribution content or description.

[Wayne Beaton]

Not that it matters much, but my take away from the Eclipse Planning
Council meeting yesterday was that we were not going to disable anybody's
aggrcon file (confirmed with Fred). My "can't recall" assertion was related
to how we'd decided to manage opt-in in a more general sense.

What I did offer was that I'd generate a participation list from the
aggrcon files and post it here to give folks a chance to verify that
everything is in order.

So... basically, if you have an aggrcon file, you're in.

Note that the participation rules
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M1_of_the_Release.29>
in the documentation state that project teams need to opt in explicitly at
least once a year (in September; so that was a requirement for the 2018-09
release).

For projects that are already participating to the Simultaneous Release,

they should announce their intent by M1 of the September release.

The challenge for us all is to detect project teams that have stopped
paying attention (thereby adding risk to the release). IMHO, the Eclipse
Planning Council will have to stand firm on disallowing projects that show
up at the last minute with big changes.

I'm thinking (I didn't share this on yesterday's call) is that it *might be*
handy to extend the XSD on the aggrcon file to include a bit more metadata
about the release (e.g. a consistent means of specifying the project id,
release version, and offset so that I can track them back to release
reviews). I'd like to try and keep all of the information in one place,
which I think will be better for everybody. Note my use of the term "might
be". But before we start making any changes, let's see what I can sort out
from the information that's already there.

Wayne

Post by Ed Willink
projects will have to make a manual *.aggrcon change anyway.

That's not mandatory. A project may ship in 2018-12 the same content as in
2018-09 thus does not need to update the *.aggrcon file.
We need something explicit about the intent, that's not correlated to the
actual contribution content or description.
_______________________________________________
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

[Wayne Beaton]

I should have added that Mickael is correct. If a project does not update
their aggrcon file, that means that they're not contributing anything new
to the release. This is expected behaviour.

The requirement is that you must configure your aggrcon file to point to a
specific version so that builds can be repeatable. This means that you must
update your aggrcon file if your team decides to contribute a new version
of project content to the release. I don't believe that this is a new
requirement.

Wayne

On Thu, Oct 4, 2018 at 9:36 AM Wayne Beaton <

Post by Wayne Beaton
Not that it matters much, but my take away from the Eclipse Planning
Council meeting yesterday was that we were not going to disable anybody's
aggrcon file (confirmed with Fred). My "can't recall" assertion was related
to how we'd decided to manage opt-in in a more general sense.
What I did offer was that I'd generate a participation list from the
aggrcon files and post it here to give folks a chance to verify that
everything is in order.
So... basically, if you have an aggrcon file, you're in.
Note that the participation rules
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M1_of_the_Release.29>
in the documentation state that project teams need to opt in explicitly at
least once a year (in September; so that was a requirement for the 2018-09
release).
For projects that are already participating to the Simultaneous Release,

they should announce their intent by M1 of the September release.

The challenge for us all is to detect project teams that have stopped
paying attention (thereby adding risk to the release). IMHO, the Eclipse
Planning Council will have to stand firm on disallowing projects that show
up at the last minute with big changes.
I'm thinking (I didn't share this on yesterday's call) is that it *might
be* handy to extend the XSD on the aggrcon file to include a bit more
metadata about the release (e.g. a consistent means of specifying the
project id, release version, and offset so that I can track them back to
release reviews). I'd like to try and keep all of the information in one
place, which I think will be better for everybody. Note my use of the term
"might be". But before we start making any changes, let's see what I can
sort out from the information that's already there.
Wayne

Post by Ed Willink
projects will have to make a manual *.aggrcon change anyway.

That's not mandatory. A project may ship in 2018-12 the same content as
in 2018-09 thus does not need to update the *.aggrcon file.
We need something explicit about the intent, that's not correlated to the
actual contribution content or description.
_______________________________________________
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

--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
LUDWIGSBURG, OCTOBER 23 - 25

[Nick Boldt]

We could ask that if you're INTENTIONALLY shipping the same bits as the
last train, you at least push a *no-op commit that confirms your intent*.

For example, this diff:

- <aggregator:Contribution xmi:version="2.0" xmlns:xmi="
http://www.omg.org/XMI" xmlns:aggregator="
http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0" label="DataTools
for *2018-09*">
+ <aggregator:Contribution xmi:version="2.0" xmlns:xmi="
http://www.omg.org/XMI" xmlns:aggregator="
http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0" label="DataTools
for *2018-12*">

Then it's super obvious, *even if the URL is the same*, that the project
intends to be in the release train and is paying attention to breakages
caused by upstream dependencies.

WDYT? Is a simple label change commit better than guessing if the bits are
compatible ?

Nick

On Thu, Oct 4, 2018 at 9:39 AM Wayne Beaton <

Post by Wayne Beaton
I should have added that Mickael is correct. If a project does not update
their aggrcon file, that means that they're not contributing anything new
to the release. This is expected behaviour.
The requirement is that you must configure your aggrcon file to point to a
specific version so that builds can be repeatable. This means that you must
update your aggrcon file if your team decides to contribute a new version
of project content to the release. I don't believe that this is a new
requirement.
Wayne
On Thu, Oct 4, 2018 at 9:36 AM Wayne Beaton <

Post by Wayne Beaton
Not that it matters much, but my take away from the Eclipse Planning
Council meeting yesterday was that we were not going to disable anybody's
aggrcon file (confirmed with Fred). My "can't recall" assertion was related
to how we'd decided to manage opt-in in a more general sense.
What I did offer was that I'd generate a participation list from the
aggrcon files and post it here to give folks a chance to verify that
everything is in order.
So... basically, if you have an aggrcon file, you're in.
Note that the participation rules
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M1_of_the_Release.29>
in the documentation state that project teams need to opt in explicitly at
least once a year (in September; so that was a requirement for the 2018-09
release).
For projects that are already participating to the Simultaneous Release,

they should announce their intent by M1 of the September release.

The challenge for us all is to detect project teams that have stopped
paying attention (thereby adding risk to the release). IMHO, the Eclipse
Planning Council will have to stand firm on disallowing projects that show
up at the last minute with big changes.
I'm thinking (I didn't share this on yesterday's call) is that it *might
be* handy to extend the XSD on the aggrcon file to include a bit more
metadata about the release (e.g. a consistent means of specifying the
project id, release version, and offset so that I can track them back to
release reviews). I'd like to try and keep all of the information in one
place, which I think will be better for everybody. Note my use of the term
"might be". But before we start making any changes, let's see what I can
sort out from the information that's already there.
Wayne

Post by Ed Willink
projects will have to make a manual *.aggrcon change anyway.

That's not mandatory. A project may ship in 2018-12 the same content as
in 2018-09 thus does not need to update the *.aggrcon file.
We need something explicit about the intent, that's not correlated to
the actual contribution content or description.
_______________________________________________
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

--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
LUDWIGSBURG, OCTOBER 23 - 25

--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
LUDWIGSBURG, OCTOBER 23 - 25
_______________________________________________
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

[Mickael Istria]

Post by Nick Boldt
We could ask that if you're INTENTIONALLY shipping the same bits as the
last train, you at least push a *no-op commit that confirms your intent*.

Sounds like a simple and good idea, which brings good traceability! Some
will update the URLs, some can update the label, or update a comment, and
looking at the history of files is enough to spot out those who might be
too far away and should be pinged.

[Karsten Thoms]

We could ask that if you're INTENTIONALLY shipping the same bits as the last train, you at least push a no-op commit that confirms your intent.
Sounds like a simple and good idea, which brings good traceability! Some will update the URLs, some can update the label, or update a comment, and looking at the history of files is enough to spot out those who might be too far away and should be pinged.

I also like the idea.

[Ed Merks]

Nick,

I agree with Mickael, this is a constructive and simple approach.

Cheers,
Ed

Post by Nick Boldt
We could ask that if you're INTENTIONALLY shipping the same bits as
the last train, you at least push a *no-op commit that confirms your
intent*.
-  <aggregator:Contribution xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:aggregator="http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0"
label="DataTools for *2018-09*">
+  <aggregator:Contribution xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:aggregator="http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0"
label="DataTools for *2018-12*">
Then it's super obvious, /even if the URL is the same/, that the
project intends to be in the release train and is paying attention to
breakages caused by upstream dependencies.
WDYT? Is a simple label change commit better than guessing if the bits
are compatible ?
Nick
On Thu, Oct 4, 2018 at 9:39 AM Wayne Beaton
I should have added that Mickael is correct. If a project does not
update their aggrcon file, that means that they're not
contributing anything new to the release. This is expected behaviour.
The requirement is that you must configure your aggrcon file to
point to a specific version so that builds can be repeatable. This
means that you must update your aggrcon file if your team decides
to contribute a new version of project content to the release. I
don't believe that this is a new requirement.
Wayne
On Thu, Oct 4, 2018 at 9:36 AM Wayne Beaton
Not that it matters much, but my take away from the Eclipse
Planning Council meeting yesterday was that we were not going
to disable anybody's aggrcon file (confirmed with Fred). My
"can't recall" assertion was related to how we'd decided to
manage opt-in in a more general sense.
What I did offer was that I'd generate a participation list
from the aggrcon files and post it here to give folks a chance
to verify that everything is in order.
So... basically, if you have an aggrcon file, you're in.
Note that the participation rules
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M1_of_the_Release.29>
in the documentation state that project teams need to opt in
explicitly at least once a year (in September; so that was a
requirement for the 2018-09 release).
For projects that are already participating to the
Simultaneous Release, they should announce their intent by
M1 of the September release.
The challenge for us all is to detect project teams that have
stopped paying attention (thereby adding risk to the release).
IMHO, the Eclipse Planning Council will have to stand firm on
disallowing projects that show up at the last minute with big
changes.
I'm thinking (I didn't share this on yesterday's call) is that
it /might be/ handy to extend the XSD on the aggrcon file to
include a bit more metadata about the release (e.g. a
consistent means of specifying the project id, release
version, and offset so that I can track them back to release
reviews). I'd like to try and keep all of the information in
one place, which I think will be better for everybody. Note my
use of the term "might be". But before we start making any
changes, let's see what I can sort out from the information
that's already there.
Wayne
On Thu, Oct 4, 2018 at 6:12 AM Mickael Istria
On Thu, Oct 4, 2018 at 12:01 PM Ed Willink
  projects will have to make a manual *.aggrcon change
anyway.
That's not mandatory. A project may ship in 2018-12 the
same content as in 2018-09 thus does not need to update
the *.aggrcon file.
We need something explicit about the intent, that's not
correlated to the actual contribution content or description.
_______________________________________________
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
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018
<https://www.eclipsecon.org/europe2018>: LUDWIGSBURG, OCTOBER
23 - 25
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018
<https://www.eclipsecon.org/europe2018>: LUDWIGSBURG, OCTOBER 23 - 25
_______________________________________________
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
<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
_______________________________________________
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

[Frederic Gurr]

+1 since it does not require changes to the aggregator schema.

Unfortunately it does not solve the underlying problem that projects
need to pay attention and actually "need to do something" to let others
know that the project is not abandoned/dead/quitting SimRel.

So instead of chasing opt-ins/opt-outs we are chasing label changes. ;)

AFAICT there is no complete technical solution to this problem, since we
can't automatically disable projects without breaking stuff.

By checking the aggregator files for changes, we can at least set up
automatic email reminders to nag projects and *hope* they reply or touch
the aggregator files.

Regards,

Fred

Post by Nick Boldt
We could ask that if you're INTENTIONALLY shipping the same bits as the
last train, you at least push a *no-op commit that confirms your intent*.
-  <aggregator:Contribution xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:aggregator="http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0"
label="DataTools for *2018-09*">
+  <aggregator:Contribution xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:aggregator="http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0"
label="DataTools for *2018-12*">
 
Then it's super obvious, /even if the URL is the same/, that the project
intends to be in the release train and is paying attention to breakages
caused by upstream dependencies.
WDYT? Is a simple label change commit better than guessing if the bits
are compatible ?
Nick 
On Thu, Oct 4, 2018 at 9:39 AM Wayne Beaton
I should have added that Mickael is correct. If a project does not
update their aggrcon file, that means that they're not contributing
anything new to the release. This is expected behaviour.
The requirement is that you must configure your aggrcon file to
point to a specific version so that builds can be repeatable. This
means that you must update your aggrcon file if your team decides to
contribute a new version of project content to the release. I don't
believe that this is a new requirement.
Wayne
On Thu, Oct 4, 2018 at 9:36 AM Wayne Beaton
Not that it matters much, but my take away from the Eclipse
Planning Council meeting yesterday was that we were not going to
disable anybody's aggrcon file (confirmed with Fred). My "can't
recall" assertion was related to how we'd decided to manage
opt-in in a more general sense.
What I did offer was that I'd generate a participation list from
the aggrcon files and post it here to give folks a chance to
verify that everything is in order.
So... basically, if you have an aggrcon file, you're in. 
Note that the participation rules
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#State_intent_early_.28M1_of_the_Release.29>
in the documentation state that project teams need to opt in
explicitly at least once a year (in September; so that was a
requirement for the 2018-09 release). 
For projects that are already participating to the
Simultaneous Release, they should announce their intent by
M1 of the September release.
The challenge for us all is to detect project teams that have
stopped paying attention (thereby adding risk to the release).
IMHO, the Eclipse Planning Council will have to stand firm on
disallowing projects that show up at the last minute with big
changes.
I'm thinking (I didn't share this on yesterday's call) is that
it /might be/ handy to extend the XSD on the aggrcon file to
include a bit more metadata about the release (e.g. a consistent
means of specifying the project id, release version, and offset
so that I can track them back to release reviews). I'd like to
try and keep all of the information in one place, which I think
will be better for everybody. Note my use of the term "might
be". But before we start making any changes, let's see what I
can sort out from the information that's already there.
Wayne
On Thu, Oct 4, 2018 at 6:12 AM Mickael Istria
  projects will have to make a manual *.aggrcon change
anyway.
That's not mandatory. A project may ship in 2018-12 the same
content as in 2018-09 thus does not need to update the
*.aggrcon file.
We need something explicit about the intent, that's not
correlated to the actual contribution content or description.
_______________________________________________
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
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018
<https://www.eclipsecon.org/europe2018>: LUDWIGSBURG, OCTOBER 23
- 25
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018
<https://www.eclipsecon.org/europe2018>: LUDWIGSBURG, OCTOBER 23 - 25
_______________________________________________
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
<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
_______________________________________________
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

[Daniel Megert]

Throwing out was discussed but after Fred's explanation, we decided not to
throw out projects.

Wayne: I can't recall which approach we prefer.

I've updated the notes accordingly.

Dani



From: Pierre-Charles David <pierre-***@obeo.fr>
To: cross-project-issues-***@eclipse.org
Date: 04.10.2018 11:21
Subject: Re: [cross-project-issues-dev] 2018-12 opt-in

No explicit opt-in is required for returning projects. We're going to
sort this out automatically from the aggregation files.

Could you clarify how exactly this will be "sorted out"? From what I
understood at yesterday's planning council meeting [1], the idea was to
disable everyone's contribution at the start of a new cycle and to
expect each project to explicitly re-enable its contribution before M1.
Is that correct?

After discussing with other project leads here at Obeo we feel this
approach (if this is indeed what is proposed) would be too disruptive.
We've tried this before, and the result was not good, with the first
milestone(s) often completely broken. It would be enough for a single
project on which others depend to be late to completely break the
aggregation. Given the reduced number of milestones we have now, this
would be really bad.

I think the idea of relying on an explicit action in "the aggregation
files" to declare intent is good, but using the enablement flag too
risky. Maybe we could have another mechanism in the repo for that. How
about something as simple as a "participation.txt" text file with a
single line per project:

PMF: 2018-12
XWT: 2018-12
actf: 2018-12
acute: 2018-12
birt: 2018-12
...

Declaring intent to participate would simply involve editing the
corresponding line with the version of the next release.

Regards,
Pierre-Charles David (Obeo)

[1]
https://wiki.eclipse.org/Planning_Council/October_3_2018


_______________________________________________
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

[Sam Davis]

Post by Wayne Beaton
No new functionality can be added in any Release Candidate. If you are
contributing new bits to this instance of the simultaneous release, you
must participate in the milestones.

Wayne, could you clarify what this means (or link to where this is
documented)? What counts as new functionality?

Thanks,
Sam
--
Sam Davis
Senior Software Engineer, Tasktop
Committer, Eclipse Mylyn
http://tasktop.com

On Wed, Oct 3, 2018 at 2:13 PM, Wayne Beaton <

Post by Wayne Beaton
No explicit opt-in is required for returning projects. We're going to sort
this out automatically from the aggregation files.
Note that aggregation files need to be authored such that builds are
repeatable. That is, you cannot point your aggregation file to the "lastest
and greatest"; it must point to a specific version of your software.
Any project that wishes to join the simultaneous release, but did not
participate in the previous iteration needs to announce their intent to
participate by the M1 date (October 19). If you are leaving the
simultaneous release, please turn off or remove your aggregation file; an
announcement on this list would be very helpful.
If your project is introducing breaking change or is otherwise adding
functionality that may have downstream impact, we expect that you will
announce these changes as early as possible via this list.
If you are planning a new major or minor release, please enter your
project's release record into the PMI by the M1 date (October 19). Release
records are not required for service releases.
Note that your project must be consistent with the IP Policy at all times.
Releases, even service releases, may only contain third party IP that has
been resolved by the IP Team.
No new functionality can be added in any Release Candidate. If you are
contributing new bits to this instance of the simultaneous release, you
must participate in the milestones.
I will be posting a complete list of dates on the wiki later today or
tomorrow. Further updates as events warrant.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
LUDWIGSBURG, OCTOBER 23 - 25
_______________________________________________
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

[Christian Dietrich]

i would be interested in a clarification too.
this forces projects to build gazillions of milestones
which might be very hard for projects that dont have the manpower
platform has.

thanks
christian

Post by Wayne Beaton
No new functionality can be added in any Release Candidate. If you are
contributing new bits to this instance of the simultaneous release, you
must participate in the milestones.