> *All bundles must be signed using the EF's certificate. *Obvious >> exceptions will be made in cases where signing is impossible. >> > >> We will be applying this standard to the next release and for every >> release thereafter. >> >> The means by which the simultaneous release participation rules are >> changed is to engage with the Eclipse Planning Council via your Eclipse >> Planning Council representative. >> > > So if I understand correctly everything from above can be changed via the > Planning Council. I'm especially interested in the signing as it's becoming > harder and harder to keep up with external ecosystem due to way faster pace > and being able to use different means of signing as discussed at > https://www.eclipse.org/lists/p2-dev/msg05910.html becomes critical. But > let's keep this discussion for the next Planning Council meeting. >
Personally, I think the entire concept of this sort of signing should be reviewed. If the editor wants to release signed artifacts then the onus should be on the editor to trust and sign everything it pushes out with the EF cert, it shouldn't export requirements to projects it consumes to themselves have things signed by the EF cert. That whole service that the EF provides for jar files to show up in some directory and signed artifacts popping out in another is hokey and combined with the concept of p2 repositories is a big reason Jetty left the release train. cheers, Jesse
_______________________________________________ cross-project-issues-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
