I agree with Igor's response. > I would rather see there only have to be _one_ signing step, that of > the final aggregation :)
This assume that everything every project produces is put into the aggregation repo. Which isn't true (and the stuff that wasn't should be signed, also). Plus, if/when projects had their "own" repo (which should frequently be true) they need their their own bundle there also signed or else there would be two bundles with same version/qualifier, one signed, one not, which isn't good. I realize that some people would like to simply provide the Java code, and have someone else build it all, sign it all, and everything else releng related. Maybe someday. But ... in the meantime ... the aggregation is just an aggregation of what already exists. Thanks for your comments though. From: Jesse McConnell <[email protected]> To: Cross project issues <[email protected]>, Date: 12/15/2011 11:49 AM Subject: Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers? Sent by: [email protected] > A better approach (for you) might be to work the test (and failure) into > your own build and promotion procedures. I would rather see there only have to be _one_ signing step, that of the final aggregation :) then you could just start signing at M1 and people could validate things are working correctly from then on cheers, jesse _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
