| Re: [cross-project-issues-dev] 2018-12 opt-in |
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.
WayneOn Thu, Oct 4, 2018 at 9:36 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> 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 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.WayneOn Thu, Oct 4, 2018 at 6:12 AM Mickael Istria <mistria@xxxxxxxxxx> wrote:_______________________________________________On Thu, Oct 4, 2018 at 12:01 PM Ed Willink <ed@xxxxxxxxxxxxx> 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
cross-project-issues-dev@xxxxxxxxxxx
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: LUDWIGSBURG, OCTOBER 23 - 25--_______________________________________________Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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