|
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:
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
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
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.
Wayne
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
“The Only
Thing That Is Constant Is
Change” - Heraclitus
_______________________________________________
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
|
