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 < [email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Thu, Oct 4, 2018 at 12:01 PM Ed Willink <[email protected]> wrote: >> >>> 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 >> [email protected] >> 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
