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