Nick,
I agree with Mickael, this is a constructive and simple approach.
Cheers,
Ed
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
_______________________________________________
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
