+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 On 04.10.2018 22:23, Nick Boldt wrote: > 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] > <mailto:[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] > <mailto:[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] <mailto:[email protected]>> wrote: > > > > On Thu, Oct 4, 2018 at 12:01 PM Ed Willink <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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 > -- Frederic Gurr Release Engineer | Eclipse Foundation Europe GmbH Annastr. 44, D-64673 Zwingenberg Handelsregister: Darmstadt HRB 92821 Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque _______________________________________________ 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
