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 < [email protected]> wrote: > 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 -- 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
_______________________________________________ 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
