Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] 6 month release cycle

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
My blog - My Tweets

Back to the top