On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:
1. New contributions are piled on, aggregation happens, problems are
found and need to be sorted out manually. Meanwhile, aggregation is
broken and more contributions pile on. The solution is to remove
direct access to aggregation metadata and process one contribution at
a time. When a contribution request is made, aggregation is performed.
If it fails, the contribution is rejected and the contributing project
gets to figure out what's wrong without affecting anyone else.
Seems like using Gerrit to process contributions into aggregator would
help. However, it means that someone has to review and merge this
contributions manually; but if this Gerrit review also triggers a
Jenkins build that validates the aggregation (without publishing it), it
wouldn't be too difficult to maintain as it would spot some errors early
and automatically.
2. Content of contributed repositories changes and some needed
repositories are deleted. The result is inability to reproduce
aggregation. The solution is policy (projects must not contribute
mutating repositories to aggregation) and enforcement (mirroring of
contributed repositories). The mirrors can be purged after a certain
period when reproducing aggregation older than a certain amount of
time is no longer necessary.
This is closely related to this discussion:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=331385 . I agree that
projects should be forced provide a stable URL with stable content to
aggregator. It should be a requirement of the release train.
If we use Gerrit and reviews to contribute to aggregator, it's would be
a criterion for vetoing a contribution.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
