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
[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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
