On 17 August 2011 13:00, Benson Margulies <[email protected]> wrote: > 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. >
And during that window, the release manager is exposed to liabilities as the Apache liability cover only applies if there are at least 3 binding votes IIUC IANAL etc. I would be happy to see fast-track votes for pom-only releases, e.g. once 3 binding +1 votes have been received. There are no binding -1's on a release, so you only need 3 binding +1's... once you have them no need to wait the 72hr -Stephen >> >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
