On Wed, Aug 17, 2011 at 7:57 AM, Stephen Connolly <[email protected]> wrote: > I take the simple view that if it ends up in > https://repository.apache.org/content/repositories/releases/ then it > is a release therefore the release voting rules apply... But I am > willing to accept if the majority want to put a different criteria on > what constitutes a release
I understand that this is how we got here. I'm offering up a proposal to tamper with this. A related scheme: lazy consensus push, and then a vote on the POM release, leaving a brief window of exposure. > > On 17 August 2011 12:55, Stephen Connolly > <[email protected]> wrote: >> That assumes that nobody outside of Apache inherits from these shared poms... >> >> A scary assumption to make IMHO >> >> On 17 August 2011 12:50, Benson Margulies <[email protected]> wrote: >>> This tees off of a remark in the recent vote thread about the >>> disruption to CI of pom releases. >>> >>> I don't believe that we need the full ASF release voting process for >>> our internal shared POMs. >>> >>> I reason as follows: >>> >>> The Apache release process creates a particular legal status for a >>> body of code. This has certain advantages for users and developers. >>> >>> However, that assumes that there are users! However, these POMs are >>> not intended for use by anything except other pieces of Maven (the >>> global ASF pom might be an exception). Thus, they should be viewed as >>> part of the releases of Maven itself and the components and plugins, >>> not as independent releases. >>> >>> To build any of our user-visible components from source, you need to >>> use the right parent POM (give our take our friend at Gentoo). >>> Arguably, what we need here is a tweak to the source plugin, or some >>> other plugin, that could sweep the chain of parents into 'the >>> release', or at least enumerate them. We could then argue that, >>> maven-release-plugin aside, the shared poms are formally 'released' >>> when the components that use them are releases. >>> >>> If this argument holds water, the shared poms could be pushed via the >>> maven-release-plugin via lazy consensus, and the CI problems go away. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
