Hi
But surely such an update should not occur.
IMHO the sequence of events is:
a) develop a new contribution and build it
b) change the *.aggrcon to reference the new contribution
c) submit the changed *.aggrcon for Gerrit build approval
d) commit the changed *.aggrcon for polled build usage
Surely the only hazard is that if a build occurs at the 'same'
instant that the GIT commit occurs, it is uncertain whether old or
new contribution is used? But there is no indeterminate
intermediate.
Any development process that updates an already contributed repo
is not playing fair.
Regards
Ed Willink
On 24/05/2017 08:46, Mickael Istria
wrote:
Hi Krum,
As far as I understand, the "legacy update site" issue may
just be the way aggragation failed because of the update,
but not the cause of the failure. We can imagine the during
the aggregation process, your repo was updated (update of
repo during aggregation isn't supported by the aggregation
process), so it put aggregation in an inconsistent state and
the aggregator wrongly reported that the cause is usage of
legacy update site.
With last message from Alexander saying everything is working
now, I think we can assume everything is back to work and stop
worrying about it.
HTH
_______________________________________________
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
